<![CDATA[TRON - Medium]]> https://medium.com/tronnetwork?source=rss----839d5c53e074---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png TRON - Medium https://medium.com/tronnetwork?source=rss----839d5c53e074---4 Medium Mon, 06 Apr 2026 04:59:01 GMT <![CDATA[Mainnet Democritus Announcement]]> https://medium.com/tronnetwork/mainnet-democritus-announcement-39ee3e3cf69c?source=rss----839d5c53e074---4 https://medium.com/p/39ee3e3cf69c Fri, 06 Feb 2026 08:02:01 GMT 2026-02-06T08:02:03.216Z

The TRON network has released the GreatVoyage-v4.8.1(Democritus) version (hereafter referred to as “Democritus”). This is a mandatory upgrade that introduces support for the ARM64 architecture, alongside several key updates and governance proposals. Please find the details below.

Core

1. Expand compatibility for ARM64 architecture and JDK 17

To further enrich the java-tron technical ecosystem, the Democritus version introduces support for the arm64 architecture. In arm64 environments, the system currently supports JDK 17 and the RocksDB database.

ARM64 architecture

  • Mandatory JDK 17: JDK 17 is the required Java runtime environment to ensure the operational stability of the node in the arm64 environments (based on JEP 237, 388, 391).
  • Mandatory RocksDB: The database only supports RocksDB (v9.7.4). LevelDB JNI does not support arm64 architecture and lacks maintenance, so the community-active RocksDB was chosen.
  • Floating point computation adaptation: Floating-point calculations have been switched to use StrictMath via a proposal to ensure consistent results across different platforms. Before the proposal took effect, differences in floating-point implementations between arm64 and x86_64 architectures could lead to inconsistent results. Therefore, on arm64 architectures, results are kept consistent with x86_64 mainnet data via hardcoding. Warning: Private networks on x86_64 platforms using floating-point computation (specifically Bancor transactions involving pow) may face synchronization issues from genesis on arm64. In such cases, please use a database snapshot from an existing height to start arm64 nodes.
  • Toolkit limitations: LevelDB-related commands (db archive and db convert) are not supported in arm64 environments.

Changes under x86_64 architecture

  • Mandatory JDK 8: Since versions higher than JDK 8 have removed Java EE modules (per JEP 320), annotations such as @PostConstruct will fail, leading to NullPointerExceptions and block synchronization failures. Democritus introduces mandatory JDK 8 validation on x86_64 to ensure environment stability.
  • RocksDB/LevelDB compatibility restrictions: Due to version discrepancies (x86_64 uses RocksDB v5.15.10 which supports LevelDB, while arm64 uses v9.7.4 which does not), forcing RocksDB to open LevelDB in an arm64 environment triggers “Database Corruption” errors. To ensure consistent cross-platform behavior and data migration, Democritus uniformly prohibits RocksDB from accessing LevelDB databases (Existing databases successfully opened via compatibility mode remain unaffected). Error prompts for LevelDB attempting to open RocksDB have also been optimized, and interfaces/exception logic have been standardized.
  • Toolkit update: Previously, db convert defaulted to a “compatibility mode” that only updated the value of engine.properties to RocksDB while keeping the underlying data in LevelDB format. To align with arm64’s strict RocksDB requirements, the db convert command has been refactored to perform a non-compatibility conversion (previously the -safe flag logic). Consequently, the -safe parameter and “compatibility mode” have been removed to ensure seamless data migration across architectures.

Other changes

JDK 17 Compatibility

  • Null pointer compatibility: Optimized null pointer prompt information to facilitate problem positioning (based on JEP 358).
  • Number conversion exception compatibility: Optimized number conversion exception prompts and added conversion radix error prompts (based on JDK-8176425).
  • JDK version parsing compatibility: Adapted to JDK 10+ version number format changes (based on JEP 223).
  • var inference keyword: Supports var type inference mechanism (based on JEP 286).

RocksDB Resource Optimization

  • Increase max handle setting parameter: Added the parameter dbSettings.maxOpenFiles, default is 5000 (previously mandatory and unconfigurable), developers can adjust according to server load.
  • Resource release optimization: Set a reasonable lifecycle for RocksDB resources to release used resources in time, avoiding potential memory leak problems.

To support JDK 17 and arm64 architecture, the following dependency changes were made:

Issue: https://github.com/tronprotocol/java-tron/issues/5954

Source Code: https://github.com/tronprotocol/java-tron/pull/6327 https://github.com/tronprotocol/java-tron/pull/6421 https://github.com/tronprotocol/java-tron/pull/6440 https://github.com/tronprotocol/java-tron/pull/6455 https://github.com/tronprotocol/java-tron/pull/6457 https://github.com/tronprotocol/java-tron/pull/6459 https://github.com/tronprotocol/java-tron/pull/6472 https://github.com/tronprotocol/java-tron/pull/6502

TVM

1. Modify the behavior of SELFDESTRUCT

Following the proposal to deprecate the SELFDESTRUCT instruction via TIP-652 in GreatVoyage-4.8.0 (Kant), the Democritus release formally introduces behavioral adjustments to SELFDESTRUCT. This change ensures deep compatibility with Ethereum’s EIP-6780, aligning the TVM (TRON Virtual Machine) with EVM standards. Detailed specifications can be found in TIP-6780.

In versions prior to Democritus, SELFDESTRUCT allowed a contract to terminate itself, transfer its funds to a designated address, and delete all associated account data (code, storage, and the account itself). Starting with the Democritus release, the behavior of the SELFDESTRUCT instruction is modified as follows:

Restricted Execution Scenarios

Account data deletion (including code, storage, and the account itself) is now only permitted if SELFDESTRUCT is invoked within the same transaction in which the contract was created.

Scenario 1: invoke SELFDESTRUCT in a Subsequent Transaction (Standard Case)

  • The contract account is not destroyed.
  • Execution of the current contract stops immediately.
  • No data is deleted, including storage keys, code, or the account itself. However, all assets (TRX, staked TRX, and TRC10 tokens) are transferred to the target address.
  • If the target address is the contract itself, the assets are not burned.

Scenario 2: invoke SELFDESTRUCT in the Same Transaction (Creation & Destruction)

  • Execution stops immediately.
  • All account data is purged.
  • All assets are transferred to the target address.
  • If the target address is the contract itself, the balance is reset to zero and the assets are burned.

Energy Cost Adjustment

To increase the threshold for usage and further mitigate abuse, the Energy cost for the SELFDESTRUCT opcode has been increased from 0 to 5,000.

NOTE: This feature is governed by TRON network parameter #94. It is disabled by default (value: 0) and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-6780.md

Source Code: https://github.com/tronprotocol/java-tron/pull/6383 https://github.com/tronprotocol/java-tron/pull/6448

Net

1. Fix “gt lastNum” and “gt highNoFork” error during block synchronizing

The synchronization service previously outputted full exception stack traces during specific edge-case scenarios involving gt highNoFork and gt lastNum errors. To better align with standard error-level logging practices, this behavior has been adjusted. The service now logs only the specific exception message, suppressing the full stack trace to reduce log noise and improve readability.

Source Code: https://github.com/tronprotocol/java-tron/pull/6381

2. Fix the light node incorrectly reporting a FORKED disconnection

In versions prior to Democritus, light nodes often misidentified connection issues as FORKED during handshakes with Full Nodes of lower block heights. This occurred specifically when a Full Node’s highest solidified block was not present on the light node’s local main chain.

The Democritus release refines this logic by introducing a specific height threshold: a FORKED status is now only triggered if the light node’s lowest block height is lower than the Full Node’s highest solidified block height. In all other cases of chain mismatch, the error is correctly categorized as LIGHT_NODE_SYNC_FAIL.

Source Code: https://github.com/tronprotocol/java-tron/pull/6375

3. Optimize P2P disconnection reason codes

Prior to the Democritus release, certain P2P_DISCONNECT messages utilized vague reason codes, hindering accurate network troubleshooting. This update refines the error reporting logic for three specific scenarios to provide clearer diagnostic data:

  • Scenario 1: If a connection is terminated because a received block fails signature verification, the reason code is updated from UNKNOWN to BAD_BLOCK.
  • Scenario 2: Previously, failures during the HelloMessage validation incorrectly triggered an UNEXPECTED_IDENTITY error, even when no identity-specific checks were performed. This has been corrected to INCOMPATIBLE_PROTOCOL to accurately reflect the validation failure.
  • Scenario 3: When a P2P_HELLO message contains a block ID with a length other than 32 bytes, the disconnection reason is now reported as INCOMPATIBLE_PROTOCOL instead of UNKNOWN.

Source Code: https://github.com/tronprotocol/java-tron/pull/6394

4. Implement P2P message rate limit

Prior to the Democritus release, P2P message processing was not rate-limited, leaving nodes vulnerable to resource exhaustion (bandwidth, CPU, and RAM) when handling high message volumes. To address this, Democritus introduces a per-peer rate limiting mechanism. If the frequency of specific messages from a single peer exceeds defined thresholds, the node will drop the messages and proactively disconnect from that peer. The following limits are applied based on message type and node state:

  • SyncBlockChainMessage: Restricted to 3 QPS during the synchronization phase (defined as ChainInventory.remainNum > 0).
  • FetchInvDataMessage: Restricted to 3 QPS during the block synchronization stage.
  • P2P_DISCONNECT: Processing is limited to 1 QPS.

Source Code: https://github.com/tronprotocol/java-tron/pull/6393

5. Optimize concurrent access to fields of PeerConnection

The Democritus release optimizes concurrent access to PeerConnection by applying the volatile keyword to shared fields and refining the sequence of variable assignments. These changes ensure thread-safe visibility and prevent race conditions, significantly reducing exceptions caused by state inconsistencies during network synchronization.

Source Code: https://github.com/tronprotocol/java-tron/pull/6360

Other Changes

Configuration & Dependencies

1. Optimize the configuration switch for zkSNARK

Added configuration item node.allowShieldedTransactionApi to replace node.fullNodeAllowShieldedTransaction.

Source Code: https://github.com/tronprotocol/java-tron/pull/6371 https://github.com/tronprotocol/java-tron/pull/6427

2. Upgrade gradle to support jitpack publish

Gradle version has been upgraded to 7.6.4, using the maven-publish plugin to support jitpack publishing.

Source Code: https://github.com/tronprotocol/java-tron/pull/6367

3. Optimize local witness initialization logic

The Democritus release refines the local witness initialization process. Private key and address initialization logic is now executed exclusively by witness nodes. If an invalid witness address is configured, the program will throw an exception and terminate. Additionally, the cryptography library has been upgraded from org.bouncycastle:bcprov-jdk15on:1.69 to org.bouncycastle:bcprov-jdk18on:1.79.

Source Code: https://github.com/tronprotocol/java-tron/pull/6368 https://github.com/tronprotocol/java-tron/pull/6452

4. Optimize log prompts for missing Blackhole configuration

The Democritus release improves the error logging for missing Blackhole account configurations. The updated logs provide more actionable guidance, explicitly notifying users to configure the Blackhole account address within the config.conf file.

Source Code: https://github.com/tronprotocol/java-tron/pull/6356

5. Enrich FullNode command-line options

Starting with the Democritus release, the standalone SolidityNode.jar and KeystoreFactory.jar have been merged into FullNode. Users can start the SolidityNode service using the command-line parameter—-solidity, or start the KeystoreFactory service using --keystore-factory. This unification reduces storage overhead and simplifies build and deployment workflows.

Source Code: https://github.com/tronprotocol/java-tron/pull/6397 https://github.com/tronprotocol/java-tron/pull/6450 https://github.com/tronprotocol/java-tron/pull/6446

6. Synchronize config.conf with tron-deployment

The Democritus version introduces full synchronization of configuration items between config.conf and the tron-deployment repository, and updates the seed node list in seed.node.ip.list.

Source Code: https://github.com/tronprotocol/java-tron/pull/6332

7. Standardize full configuration and annotation guidelines

The Democritus version introduces a standardized configuration file containing all supported parameters. Any configuration item not included in this file is considered invalid or deprecated. Additionally, this release defines specific annotation and commenting standards within the configuration files:

  • Whole-line comments Must begin with the # prefix.
  • Comments appended to the end of a configuration line may use either # or //.
  • Configuration items without default values must be prefixed with # to serve as a commented-out template.

Source Code: https://github.com/tronprotocol/java-tron/pull/6430

8. Update dependencies

Upgraded dependencies such as grpc-java, spring, jackson, and jetty:

Deleted dependencies:

Additionally, the Democritus version upgrades the underlying network library libp2p, from 2.2.6 to 2.2.7. This version not only adds compilation support for JDK 17 but also introduces numerous optimizations and improvements:

  • Added formal compilation support for JDK 17 (#113).
  • Upgraded grpc-netty and protobuf libraries (#110).
  • Optimized connection pool (connPool) and general resource allocation logic (#116).
  • Implemented a concurrent external IP acquisition mechanism with built-in validation (#120, #121).
  • Refined network detection logic (#122).

Source Code: https://github.com/tronprotocol/java-tron/pull/6400 https://github.com/tronprotocol/java-tron/pull/6429 https://github.com/tronprotocol/java-tron/pull/6431 https://github.com/tronprotocol/java-tron/pull/6481

9. Update code version to 4.8.1

The version number has been formally defined as 4.8.1 to reflect the Democritus release.

Source Code: https://github.com/tronprotocol/java-tron/pull/6445

Event Service

1. Optimize transaction info retrieval logic for Event Services

The Democritus release addresses compatibility issues encountered during the retrieval of transaction info. To ensure data availability, if the event service fails to retrieve data from the transactionRetStore database, it will automatically perform a compatibility fallback to retrieve data from the transactionHistoryStore database.

Source Code: https://github.com/tronprotocol/java-tron/pull/6443 https://github.com/tronprotocol/java-tron/pull/6453

2. Remove bloom filter write toggle

The section-bloom database is used to store bloom filters for contract logs and their corresponding block indexes. When processing eth_getLogs requests, the node queries this database to quickly locate matching blocks. This is a critical step for efficient event retrieval.

Prior to the Democritus Release, writing to this database was controlled by the node.jsonrpc.httpFullNodeEnable configuration. If this setting was disabled, the node would not record block bloom filter data to the section-bloom database. Because these index data points cannot be retrospectively backfilled automatically, users were unable to query historical transaction events that occurred while the toggle was off — even if they enabled the configuration later.

Starting with the Democritus version, dependency on this configuration toggle has been removed. The node now persistently writes data to the section-bloom database by default. This change ensures the continuity and integrity of the bloom filter index, completely resolving the issue where eth_getLogs failed to retrieve historical data due to specific configuration states.

Source Code: https://github.com/tronprotocol/java-tron/pull/6372

3. Optimize event service shutdown logic

The Democritus version introduces an optimized shutdown logic for the HistoryEventService thread. By implementing a global state variable, isClosed, the system now ensures that resource deallocation occurs exactly once, even if the close function is invoked multiple times. This optimization effectively prevents redundant resource disposal and associated exceptions, significantly enhancing system stability during termination.

Source Code: https://github.com/tronprotocol/java-tron/pull/6463

Test Case

1. Optimize resource management for test cases

The Democritus version introduces a systematic optimization of resource management for unit testing. These enhancements significantly improve execution efficiency while further ensuring the cleanliness and stability of the testing environment.

  • Standardized Cleanup Mechanism: Implemented a more rigorous file cleanup protocol to ensure that all temporary data generated during testing is thoroughly removed post-execution.
  • Improved Execution Performance: By optimizing high-latency test cases, the total duration of the unit testing suite has been reduced by up to 30%.
  • Robust Resource Release: Addressed known resource leak issues and standardized the resource release logic.
  • Enhanced Runtime Stability: Resolved specific NullPointerExceptions.

Source Code: https://github.com/tronprotocol/java-tron/pull/6437 https://github.com/tronprotocol/java-tron/pull/6483 https://github.com/tronprotocol/java-tron/pull/6486

2. Implement gRPC timeout mechanism

When executing test cases repeatedly (e.g., over 100 times) on arm64, certain gRPC test cases would hang. To solve this, the Democritus version introduces a gRPC timeout mechanism. A 5-second execution timeout was added for individual gRPC test case, and a 30-second timeout for the entire test execution; if it times out, it breaks and continues executing subsequent logic.

Source Code: https://github.com/tronprotocol/java-tron/pull/6441 https://github.com/tronprotocol/java-tron/pull/6460

3. Ensure automated termination of unit test

The Democritus version introduces optimizations to the termination logic of the ConditionalStopTest unit test. Specifically, within SR scenarios, the logic has been refined to accurately identify stop conditions even when the block production sequence undergoes changes. This ensures that the unit test terminates correctly and automatically as expected.

Source Code: https://github.com/tronprotocol/java-tron/pull/6469

4. Enhance log context isolation mechanism

The Democritus version addresses the issue of global logger configuration pollution previously triggered by the TronErrorTest unit test. By strengthening the output of error and warning messages during the LogService configuration loading phase and explicitly restoring the logger context within unit tests, the system now ensures complete log environment isolation between different test cases. This improvement eliminates interference in logging behavior across test suites and provides clearer diagnostic data for rapidly locating Logback configuration loading anomalies.

Source Code: https://github.com/tronprotocol/java-tron/pull/6476

5. Resolve CheckStyle violations in test cases

Added a line break to a comment statement in the test case file to fix checkStyle issues in test cases.

Source Code: https://github.com/tronprotocol/java-tron/pull/6392

Documents

1. Update readme for FullNode startup JVM parameters

Adjusted the JVM startup parameters for java-tron on x86_64 and arm64 platforms, aiming to ensure that FullNode nodes can meet basic disaster recovery requirements under minimum hardware configurations; meanwhile, modified hardware requirements to recommend more stable machine configurations.

Source Code: https://github.com/tronprotocol/java-tron/pull/6478

2. Fix README badge display errors

The Democritus version fixed the issue where the GitHub badge at the top of the README document displayed as “unknown”, and modified the badge image link.

Source Code: https://github.com/tronprotocol/java-tron/pull/6340

3. Update telegram info and doc link in README

The Democritus version udpated the README document to add Telegram contact information for the official TRON development discussion group.

Source Code: https://github.com/tronprotocol/java-tron/pull/6364

Others

1. TIP-767: Transitioning voting window configuration to chain governance

To ensure high uniformity of governance parameters across the entire network and enhance protocol consistency, the Democritus version introduces TRON №.92 network parameter (PROPOSAL_EXPIRE_TIME), transitioning the configuration of proposal expiration time to on-chain governance.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-767.md

Source Code: https://github.com/tronprotocol/java-tron/pull/6399 https://github.com/tronprotocol/java-tron/pull/6454

2. Fix protocol buffer syntax compatibility issue

Fixed the hexadecimal casing error in the ReasonCode struct, resolving compilation compatibility issues in JavaScript environments.

Source Code: https://github.com/tronprotocol/java-tron/pull/6426

API

1. Introduce the eth_getBlockReceipts API

The Democritus version introduces the eth_getBlockReceipts interface, used to query all transaction receipts in a specified block. For genesis blocks, blocks already pruned by light nodes, and unproduced blocks, it returns null.

  • Parameters: Block identifier (required). Supports three types: a block number represented as a hexadecimal string, a block hash (with or without the 0x prefix), or a block tag ("latest", "earliest", "finalized").
  • Returns: An array of objects. Each object is a receipt for a transaction within that block, and follows the same structure as the response returned by eth_getTransactionReceipt.

Source Code: https://github.com/tronprotocol/java-tron/pull/6379 https://github.com/tronprotocol/java-tron/pull/6433

2. Introduce a new API to query the real-time vote count of witness

The Democritus version introduces the getPaginatedNowWitnessList interface. This endpoint is designed to query real-time voting data for the current epoch and return a paginated list of witnesses sorted in descending order of their vote counts.

Parameters

  • offset: long, start index, requires >= 0.
  • limit: long, number of items to return, requires > 0, upper limit is 1000.
  • visible: boolean, optional; controls whether the returned address is in base58check or hex format.

Returns

  • Success: witnesses array, each item is a Witness (containing address, vote count, URL, etc.), sorted descending by “real-time votes”.
  • Failure: No result. When invalid parameters (e.g., limit <= 0, offset < 0, or offset >= total Witness count) returns {}, http code = 200.

API-specific errors: When in a maintenance period and requesting non-solidified data, throws a maintenance period unavailable exception, http code = 200.

Source Code: https://github.com/tronprotocol/java-tron/pull/6373 https://github.com/tronprotocol/java-tron/pull/6451

3. Optimize the return data of eth_call

In versions prior to Democritus, the eth_call interface provided limited feedback upon contract execution failure. It typically returned a generic error message (e.g., “REVERT opcode executed”) while leaving the data field empty. This lack of detailed execution context made it difficult for developers to diagnose and trace specific issues within the smart contract.

The Democritus version introduced JsonRpcException as the base class for all JsonRpc exceptions, and a JsonRpcErrorResolver class for data field generation logic.

Using the demo contract as an example, the following information was returned when calling the testInsufficientBalance method prior to the change:

{
 "jsonrpc": "2.0",
 "id": 1,
 "error": {
    "code": -32000,
    "message": "REVERT opcode executed",
    "data": "{}"
  }
}

After modification: The data field returns error information (e.g., encoded revert reason), allowing developers to obtain the specific error reason via ABI parsing. (Consistent with Ethereum node strategy, returns unparsed data for everything except default Error(string)).

{
 "jsonrpc": "2.0",
 "id": 1,
 "error": {
    "code": -32000,
    "message": "REVERT opcode executed",
    "data": "0xcf47918100000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000064"
  }
}

Source Code: https://github.com/tronprotocol/java-tron/pull/6369

4. Performance optimization for eth_getLogs, eth_getFilterLogs

Event query interfaces like eth_getLogs rely on a partialMatch function to query the bloom database. The query conditions are derived from 3 bitIndexes generated for each topic or address. Since the bloom filter has a bit limit (2048 bits), when the number of topics reaches 683, the total number of indexes (683 * 3 > 2048) exceeds the filter capacity. This inevitably leads to bit collisions and redundant bitIndexes, resulting in duplicate database queries. To address this, the proposed optimization implements de-duplication of bitIndexes prior to execution, significantly reducing the frequency of database lookups.

The table below contrasts the duplication rate of bitIndex and execution time of partialMatch under different numbers of topics and addresses. It shows that as the number of topics increases, the higher the bitIndex duplication, the more significant the performance improvement after optimization.

Source Code: https://github.com/tronprotocol/java-tron/pull/6370

To a wise and good man the whole earth is his fatherland. — — Democritus

Mainnet Democritus Announcement was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[What is TIP-6780?]]> https://medium.com/tronnetwork/tip-6780-change-to-the-selfdestruct-opcode-b992ed3885e6?source=rss----839d5c53e074---4 https://medium.com/p/b992ed3885e6 Tue, 18 Nov 2025 09:27:28 GMT 2025-11-19T05:29:55.392Z

1. Background

TIP-652 proposed the deprecation of the SELFDESTRUCT opcode. This change discouraged its use in newly deployed contracts and suggested its functionality may be further limited in future TVM upgrades.

As an EVM-compatible public chain, TRON has introduced TIP-6780 to align with Ethereum’s EIP-6780 and maintain behavioral consistency with the EVM.

2. Changes

Previously, the SELFDESTRUCT opcode allowed a contract to destroy itself, transfer its entire balance to a specified address, and subsequently delete all associated data of the contract account (i.e., code, storage, and the account itself).

2.1 Core Change: Restriction on SELFDESTRUCT Usage Scenarios

Account data (i.e., code, storage, and the account itself) is only deleted if SELFDESTRUCT is executed within the contract’s creation transaction.

Scenario 1: SELFDESTRUCT Called in a Different Transaction (Default Case)

  • The account is not actually destroyed.
  • The current contract’s execution halts immediately.
  • No data is deleted, including storage keys, code, or the account itself.
  • However, all assets held by the contract (TRX, staked TRX, TRC-10 tokens) are transferred to the target address.
  • If the target address is the contract itself, the assets are not burned.

Scenario 2: SELFDESTRUCT Called in the Same Transaction (Immediate Self-Destruction after Creation)

In this scenario, the opcode’s legacy behavior is retained:

  • The current contract’s execution halts immediately.
  • All account data is deleted.
  • All assets are transferred to the target address.
  • If the target address is the contract itself, its balance is set to 0, and the assets are burned.

2.2 Energy Cost Adjustment

The fixed Energy cost of the SELFDESTRUCT opcode is adjusted from 0 to 5,000. This raises the execution cost to further deter misuse.

​3. Impact

3.1. Impact on Developers and Smart Contracts

Hard Fork Requirement: This TIP is a consensus layer change that must be implemented via a hard fork.

TRX Burning Behavior: Previously, with SELFDESTRUCT, a contract could burn its TRX by specifying itself as the target address. Now, this action is restricted:

  • If the contract was not created in the current transaction, its TRX will not be burned, and no transfer occurs.
  • TRX can only be burned if the contract is created and SELFDESTRUCT is called within the same transaction.

Invalidated Design Patterns: Some solutions that rely on SELFDESTRUCT to implement security mechanisms or proxy upgrades are no longer secure or effective. For example:

  • The pattern of using CREATE2 + SELFDESTRUCT to implement “upgradeable contracts” is broken.
  • The practice of relying on SELFDESTRUCT to destroy an account to protect sensitive data is no longer viable.

3.2. Impact on the TRON Ecosystem

  • Enhanced Ethereum Compatibility: This change improves alignment with the EVM, simplifying the migration and integration of cross-chain infrastructure, developer tools, and decentralized applications (DApps).
  • Improved Contract Security: This change encourages developers to adopt more robust and predictable contract design patterns, moving away from opcodes that are considered unstable or are planned for future deprecation.

3. TRON On-Chain Data Analysis

3.1 Analysis of Contracts Containing the SELFDESTRUCT Opcode

Table 1: Contracts containing SELFDESTRUCT on TRON, by Asset Value.

As shown in the table, the number of contracts containing the SELFDESTRUCT opcode is very low, and the number of such contracts holding assets is even lower. Furthermore, none of these contracts have executed an actual SELFDESTRUCT transaction. The opcode is generally included as a mechanism to transfer assets out of the contract, a functionality that will remain unaffected after this proposal is implemented.

3.2 Analysis of SELFDESTRUCT Transactions

Figure 1: Example of the “create-then-destroy” pattern shown in TRON’s internal transactions.
  1. An analysis of data from 2025 (up to October 17) reveals 957,324 internal transactions involving SELFDESTRUCT. The overwhelming majority — 957,316 (99.999%) — followed an identical pattern: the contract was created and self-destructed within the same transaction. This specific use case will not be affected after this proposal is implemented.

    The remaining 8 transactions show a similar pattern: the contracts were also self-destructed on the same day they were created, and these addresses were never reactivated or reused after destruction.
  2. A historical analysis of all SELFDESTRUCT transactions confirms that addresses that have self-destructed were never re-created afterwards.

4. Conclusion

This proposal restricts the functionality of the SELFDESTRUCT opcode to enhance compatibility with Ethereum. Developers are strongly advised to avoid using SELFDESTRUCT in new smart contracts and instead adopt safer, more maintainable patterns for contract lifecycle management.

The change to the SELFDESTRUCT opcode will be included in an upcoming version release. Once released, it must be activated via network governance voting to take effect. Please stay tuned for the latest updates on the proposal via TRONSCAN.

What is TIP-6780? was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Committee Proposal 103]]> https://medium.com/tronnetwork/committee-proposal-103-3d00872aaba0?source=rss----839d5c53e074---4 https://medium.com/p/3d00872aaba0 Thu, 26 Jun 2025 06:19:04 GMT 2025-06-26T06:18:47.354Z

Committee Proposal №103 is a voting request aimed at enabling chain parameters №83, №88, and №89 on the TRON network. These changes align the TRON Virtual Machine (TVM) with the Ethereum Cancun upgrade and introduce optimizations to the consensus layer’s verification mechanism. Please refer to here for the origin discussion. The № 103 committee proposal is already in effect, please refer to here for the voting details.

The proposal has officially taken effect as of 2025–06–26 14:00 (SGT). And this post provides a detailed breakdown of the proposal’s content and significance.

What does this proposal include?

Proposal 103 activates parameters defined in the following four TIPs:

TIP-650: Transient Storage Opcodes

Two new EVM-compatible opcodes are enabled:

  • TLOAD (0x5c) — Load from transient storage
  • TSTORE (0x5d) — Store to transient storage

Transient storage offers an energy-efficient alternative to memory for storing temporary data across internal calls within the same transaction, without persisting data beyond the transaction.

TIP-651: Memory Copy Instruction

One new opcode is enabled:

  • MCOPY (0x5e) — Copy memory efficiently from one location to another

This instruction provides energy optimization for contracts that need to manipulate memory regions directly.

TIP-745: BLOB Opcodes for Cancun Compatibility

Two new opcodes are enabled in placeholder form:

  • BLOBHASH (0x49)
  • BLOBBASEFEE (0x4a)

While these opcodes return default values (0) for now, they ensure forward compatibility with Ethereum Cancun bytecode.

TIP-694: Consensus Layer Verification Enhancements

This proposal strengthens validation logic in the consensus layer:

  • Enforces a maximum size for account creation transactions to prevent bandwidth abuse
  • Validates total transaction sizes more strictly to avoid exceeding block limits
  • Ensures that the number of transaction results matches the number of invoked contracts
  • Applies stricter filtering for near-expiry transactions to preserve network bandwidth

What’s the benefit brought by this proposal?

For Virtual Machine (TVM) Compatibility:

  • Ensures alignment with Ethereum Cancun specs
  • Maintains bytecode-level compatibility with the EVM
  • Simplifies smart contract migration from Ethereum to TRON
  • Provides developers with the same energy-saving improvements

For Consensus Layer Security and Efficiency:

  • Strengthens block verification during sensitive periods (e.g., maintenance windows)
  • Prevents malicious blocks with non-standard timestamps
  • Refines Super Representative (SR) ranking algorithm for rare edge cases
  • Mitigates risk from oversized or malformed transactions

Additionally, this proposal sets the groundwork for enhanced cross-platform compatibility in the future by signaling a transition from java.lang.Math to deterministic math libraries in Java-Tron. This ensures consistent behavior across environments and JDK versions.

Summary

Committee Proposal 103 enables TRON’s compatibility with the Ethereum Cancun upgrade and significantly enhances consensus layer verification. With the activation of new opcodes and stricter validation rules, the TRON network further improves its performance, security, and developer-friendliness.

The TRON Virtual Machine is now Cancun-compatible — enabling seamless DApp migration, cross-chain development, and more efficient contract execution.

Committee Proposal 103 was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Committee Proposal 102]]> https://medium.com/tronnetwork/committee-proposal-102-feced698a9ee?source=rss----839d5c53e074---4 https://medium.com/p/feced698a9ee Fri, 13 Jun 2025 06:26:13 GMT 2025-06-13T06:24:54.418Z

Committee proposal 102 is a voting request for modifying the № 5 and № 31 chain parameters on TRON network, adjusting the block reward from 16 TRX to 8 TRX, and the voting reward from 160 TRX to 128 TRX. Please refer to here for the origin discussion. The № 102 committee proposal is already in effect, please refer to here for the voting details, this post is dedicated to provide more details.

Why does the TRON network need this proposal at this time?

The implementation of a series of proposals within TRON’s tokenomics model has significantly impacted the TRX supply, resulting in a transition from inflation to deflation, but with a potential rebound trend showing recently. Especially after increasing the total energy limit from August to October 2024, the net increase of TRX supply shows a gradual increasing trend in recent months, indicating a potential resurgence of inflation.

Fig. 1 — The TRX supply shows a deflationary trend since 2022
Fig. 2 — The net increase of TRX supply shows a positive number some days in recent months

The feasibility and reasonability of this proposal

The community has widely and deeply discussed this proposal on Github and during multiple core devs community calls, and finally made consensus on enabling this proposal.

The previous TRX block rewards effectively stimulated network staking and transaction volume growth in the early stages. However, as the TRON network develops, the relatively high production rates of TRX may dilute the token’s value over time and reduce the incentive for long-term staking.

By reducing the TRX reward from 176 TRX to 136 TRX in total, the expected annual deflation rate will become about 1.29%, which better adapts the transaction volume and activities on the TRON network.

Diving into other mainstream public chains, most have designed mechanism to control the inflation rate:

  • BTC is well-known for halving every 4 years to cut the supply.
  • ETH implemented EIP-1599 introducing base fee to accelerate burning in 2021, and significantly reduced ETH supply rate after the merge in 2022, bringing the inflation rate drop from about 4% to 0.3% at the moment, reduced by about 90%.
  • SOL supply rate is pre-set, currently about 5.1%, and is designed to decrease by about 15% each year.

The current supply rate of TRX has remained for more than 5 years, as the total energy limitation has been enlarged a lot and many chain parameters have been adjusted, it’s time to consider the proper TRX supply rate.

The biggest question during the discussion is that reducing TRX reward will decrease the benefit of staking holders. However, taking the advantage of energy renting into consideration, the expected comprehensive APR will change from about 9.15% to 7.08%, which is still attractive and competitive.

What’s the benefit brought by this proposal?

Enabling this calculation performance optimization brings several benefits:

  • Enhance Deflation: Lowering the TRX block rewards will enhance the network’s deflation rate, potentially increasing its value.
  • Incentivize Staking: Leveraging the advantage of TRON’s staking model, the increase in TRX value can encourage more users to stake TRX to obtain the resources for transactions.
  • Strengthen Network Security: Increased staking participation strengthens the network’s security by locking up more TRX.
  • Improve Economic Incentives: Align token distribution with the maturity of the network, ensuring that incentives remain robust and meaningful for both new participants and long-term holders.

Summary

After the proposal of reducing TRX reward takes effect, the annualized deflation rate of TRX is expected to increase from the previous 0.85% to 1.29%, which will further accelerate the deflation process of TRX, optimize TRON’s economic model, and enhance the long-term sustainability of the network.

Committee Proposal 102 was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[TRON Virtual Machine vs Ethereum Virtual Machine]]> https://medium.com/tronnetwork/tron-virtual-machine-vs-ethereum-virtual-machine-41e65b4f9f34?source=rss----839d5c53e074---4 https://medium.com/p/41e65b4f9f34 Thu, 15 May 2025 10:47:13 GMT 2025-05-15T10:45:04.393Z

The TRON Virtual Machine (TVM) exhibits fundamental compatibility with the Ethereum Virtual Machine (EVM), with notable distinctions in the following aspects:

  1. The TVM employs an Energy model instead of the Gas model. energyPrice is a network parameter (it can be changed by committee proposals), currently set at 210 SUN on Mainnet. Unlike the fluctuating Gas prices and the presence of a basefee in the EVM, the TVM’s GASPRICE and BASEFEE opcodes both return the energyPrice.
  2. The Energy consumption of the majority of TVM opcodes aligns with their EVM counterparts, with certain opcodes exhibiting lower Energy costs, such as SLOAD and CALL.
  3. The prefix for contract addresses generated via CREATE2 in the TVM is different from the EVM. The TVM utilizes the 0x41 prefix, determined by the formula (where ++ represents string concatenation):

    keccak256(0x41++ address ++ salt ++ keccak256(init_code))[12:]
  4. TRX can be transmitted to contracts through two mechanisms: standard transfers and TriggerSmartContract invocations carrying a callValue. Standard transfers bypass the execution of the contract’s fallback function.

Differences in Instructions

Differences in Precompiled Contracts

New Features of the TVM

Instructions

Precompiled Contracts

TRON Virtual Machine vs Ethereum Virtual Machine was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Security Guide for Smart Contracts]]> https://medium.com/tronnetwork/security-guide-for-smart-contracts-87a7ed6f90f2?source=rss----839d5c53e074---4 https://medium.com/p/87a7ed6f90f2 Mon, 12 May 2025 04:34:15 GMT 2025-05-12T04:31:56.850Z

Please note that this guide provides general recommendations. Security audits and testing tailored to specific business logic and contract requirements are still necessary in actual projects.

1. Understanding the TRON Ecosystem

Differences between the TRON Virtual Machine (TVM) and the Ethereum Virtual Machine (EVM)

  • While TRON shares similarities with Ethereum in the execution logic of the underlying virtual machine, differences exist in opcodes, resource models, and event handling mechanisms. Developers should thoroughly understand these distinctions to avoid potential security risks caused by directly applying EVM-centric patterns to the TVM.

TRC Standards and Interfaces

  • Common token standards in the TRON ecosystem include TRC-10, TRC-20, and TRC-721 (NFT). These are similar to Ethereum’s ERC-20 and ERC-721 but differ in implementation details. Developers should carefully review and cross-reference the TRC standard specifications when implementing contract logic.

Network and Account Model

  • On the TRON Mainnet, contract transaction execution consumes resources (Energy and Bandwidth). These resources’ consumption patterns and contract invocation costs differ from Ethereum’s gas model. Developers should carefully evaluate resource consumption and the potential for resource depletion during contract development and security audits.

2. Contract Security Design Principles

Principle of Least Privilege

  • In contract design, ensure that only essential functions or roles execute high-risk operations, minimizing function call permissions that can critically impact the contract state.
  • Implementing multi-role management or a multi-signature (multisig) mechanism is recommended to restrict critical operations, such as contract upgrades, core parameter modifications, and large-amount asset transfers.

Keep It Simple & Stupid (KISS) Principle

  • The more complex the smart contract logic, the greater the risk of introducing unintended vulnerabilities or unexpected state changes. Developers should decompose contracts into smaller, focused modules designed according to the “Single Responsibility Principle” to avoid redundant and unnecessary features.

Strict Input and Output Data Validation

  • Functions should check input parameters for valid boundary, type, and permission, and logically verify return values to prevent issues such as numerical overflows and erroneous state updates.

Safe Mode and Emergency Strategies

  • Design an emergency stop (Circuit Breaker / Pausable) mechanism for contracts to halt critical functions or freeze the contract upon detecting significant security risks, thereby preventing further financial losses or the spread of erroneous states.
  • Develop emergency repair or migration plans before project launch to avoid reactive and disorganized responses in the event of an incident.

3. Common Security Risks and Prevention Essentials

Reentrancy Attacks

  • As one of the most well-known attacks on Ethereum, reentrancy also remains a concern on TRON. If a contract calls an external contract or sends TRX, the external contract might call back into the original contract’s function, potentially violating the original contract function’s security assumptions.

Typical prevention measures:

  • Update the contract state before calling external contracts or performing transfers.
  • Use function-level mutual exclusion mechanisms (such as mutex or reentrancyGuard); similar logic can be designed within the TVM framework.
  • Ensure external calls occur as the last line of contract logic.

Integer Overflow/Underflow

  • Solidity compiler versions on TRON can also encounter integer overflow and underflow issues (as seen in earlier compiler versions). Using a newer compiler (with built-in security checks) or manually incorporating a secure math library, such as SafeMath, is recommended.
  • Developers should familiarize themselves with the security checks implemented by the compiler versions they use. If using an earlier version, be sure to incorporate SafeMath or equivalent protections.

Access Control Vulnerabilities

  • Missing or inadequate permission modifiers or validation on contract functions can enable attackers to invoke administrative functions.
  • Developers should manage critical functions using either a modifier (such as onlyOwner / onlyAdmin) or role-based access control components. Sensitive operations may require secondary confirmation via multi-signature contracts.

Random Number Security

  • Generating random numbers on the blockchain is a common challenge, as they are susceptible to manipulation by miners or nodes. This also applies to the TRON network.
  • Contracts that require random numbers (such as lottery or raffle contracts) should integrate off-chain random numbers or use a trusted third-party oracle. Random values generated locally via block.hash, now, or other similar methods are insecure.

Logic Flaws and Business Risks

  • For contracts involving financial assets, business logic issues should also be considered in addition to code implementation. For example, the transfer logic, lock-up logic, and minting/burning functionalities of token contracts should be evaluated for potential abuse or unauthorized access.
  • Independent threat modeling is necessary: Scrutinize each business functionality from an attacker’s perspective to assess its risk of manipulation or exploitation.

Upgrade and Migration Risks

  • TRON smart contracts, once deployed, cannot be easily modified. When using proxy contracts or upgradeable contract architecture for contract upgrades or migrations, carefully address the security risks associated with the proxy pattern:
  • Upgrade procedures require strict permission and multi-signature verification.
  • Proxy contract logic can introduce complexities such as additional storage collisions and delegatecall vulnerabilities.

4. Security Development and Audit Process Recommendations

Use a Reliable Development Toolchain

  • Select official or mature community-maintained TRON development tools (such as TronBox, TronGrid, and TronLink) and utilize established code auditing tools for static and dynamic testing.
  • When choosing third-party libraries, ensure the versions you use are secure and reliable.

Phased Testing

  • Unit Test: Test individual contract functions, particularly for core logic and high-risk permission functions.
  • Integration Test: Conduct integration testing of the entire business process in a local private network environment or on a testnet.
  • Security Audit: Use a professional audit team or an audit platform/tool for source code auditing and dynamic analysis of the contract.
  • Bug Bounty Program: In the period surrounding Mainnet launch, encourage white hat hackers and the security community to participate in vulnerability discovery and offer rewards.

Log and Event Monitoring

  • Design and trigger contract events effectively to enable blockchain explorers and monitoring scripts to track key state changes and detect potential anomalies.
  • Set up real-time monitoring and alert thresholds for critical events, including transfers, permission changes, and upgrade operations.

Multi-Signature and Custody

  • Introducing a multi-signature mechanism can significantly reduce the risk of single-point-of-failure when managing contract assets or performing critical contract operations.
  • For large projects or projects involving high-value assets, consider using secure custody service providers or hardware wallets to manage private keys.

5. Operation and Continuous Security Assurance

Version Control and Traceability

  • Implement version control for smart contracts. After contract deployment, promptly record and publicly disclose the contract address, ABI, source code hash, and other relevant information to facilitate tracking and auditing of updates by users and audit institutions.
  • If performing contract upgrades or migrations, publicly disclose the upgrade process, explain the differences between old and new versions, and provide data migration plans.

Timely Response to Community and Industry Developments

  • Follow security vulnerabilities, compiler bugs, developer warnings, and other relevant information released by the TRON or other security communities, and promptly patch potential issues.
  • Continuously update threat models and security strategies to address emerging attack methods (such as flash loan attacks and oracle manipulation).

Compliance and Legal Risks

  • If the project involves financial or securities attributes (such as exchanges, collateralized lending), consult with legal counsel and complete necessary filings to ensure regulatory compliance.
  • Adhere to relevant laws, regulations, and industry best practices to protect user assets and privacy.

Security Guide for Smart Contracts was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Event Service Framework V2.0]]> https://medium.com/tronnetwork/event-service-framework-v2-0-0622f2f07249?source=rss----839d5c53e074---4 https://medium.com/p/0622f2f07249 Tue, 29 Apr 2025 09:53:11 GMT 2025-04-29T09:52:59.175Z

TRON features an event service mechanism that enables developers to receive and process on-chain events via custom event plugins. The overall architecture of the event service is as follows: The event service retrieves and encapsulates on-chain event information, then writes this data to an event cache queue for asynchronous consumption by the event plugin. Upon receiving the event data, the plugin can write the data to databases, message queues, or other target systems based on business requirements to further support upper-layer applications.

In the event service framework V1.0 (hereafter the V1.0 framework or V1.0), the encapsulation of event data and the operation of writing data to the queue were highly coupled with the block execution process:

  • Transaction Execution Phase: Encapsulates contract event data (contractEventTrigger) and contract log event data (contractLogTrigger);
  • Block Execution Phase: Encapsulates block event data (blockTrigger) and transaction event data (transactionTrigger).

Following encapsulation, the event data was immediately written to the event queue for subsequent processing by the event plugin. The overall process flow is illustrated in the following diagram:

Due to the coupling of the event processing logic with the block processing flow, any event service anomaly could cause block processing failures, thereby impacting block broadcasting and synchronization. Additionally, V1.0 did not support historical event replay and lacked an event push rate control mechanism, making it inadequate for complex application scenarios.

To address these issues, TRON introduced the event service framework V2.0 (hereafter the V2.0 framework or V2.0) in the GreatVoyage-v4.8.0 (Kant) release. This framework decouples the event processing logic from the block execution flow, restructuring it as an independent module, which significantly enhances system stability and scalability. Concurrently, V2.0, while preserving the independence of the block processing flow, supports historical event replay and incorporates an event push rate control mechanism, effectively improving the applicability and robustness of the event service across various use cases.

Event Service Framework V2.0 Overview

This document will provide a detailed explanation of the V2.0 framework, covering the following key aspects:

  • Independent Event Service Module
  • Historical Event Replay Feature
  • Consumption Rate Awareness Mechanism

Independent Event Service Module

In V2.0, the event service is designed as an independent module, achieving complete decoupling from the core block processing logic. This module neither depends on other business modules nor can it be directly invoked by them.

Upon startup, the event service reads block data from the database, then encapsulates the required event types based on user-configured event subscription options. The encapsulated event data is then placed into the event queue for subsequent processing by the event plugin.

This architecture significantly enhances system flexibility, stability, and scalability, especially effective for complex or high-concurrency application scenarios.

Core Data Structure

BlockEvent: Represents the complete set of event data for a block. It includes:

  • Block Event Data (blockTrigger)
  • Transaction Event Data (transactionTrigger)
  • Contract Event Data (contractEventTrigger)
  • Contract Log Event Data (contractLogTrigger)

In contrast to V1.0, which processed event data separately, V2.0 completes the unified encapsulation of all event data in a single load operation.

Core Interface

BlockEvent getBlockEvent(long blockNum): Reads data related to the specified block height from the database, encapsulates the event data, and returns a BlockEvent object.

Core Threads

BlockEventLoad (Data Loading Thread): Reads block-related data from the database and encapsulates event data. The encapsulated data is then passed to the following threads for processing:

  • RealtimeEventService (Real-time Event Processing Thread): Processes event data for new blocks.
  • SolidEventService (Solidified Block Event Processing Thread): Processes event data for newly solidified blocks.

The following diagram illustrates the thread collaboration:

Historical Event Replay Feature

V2.0 introduces the historical event replay feature, addressing V1.0’s limitation of only supporting real-time event pushing.

In V1.0, events were only pushed to subscribers in real time when new blocks were processed, with no support for replaying events from historical blocks.

V2.0 now supports processing and pushing events from local historical blocks, meeting user demand for historical data subscriptions. This feature can be configured via the following option:

event.subscribe.startSyncBlockNum = <starting block height>
  • startSyncBlockNum <= 0 indicates that the historical event synchronization feature is turned off.
  • startSyncBlockNum > 0 indicates that this feature is turned on, and historical events will be synchronized starting from the specified block height. (Note: Enabling this feature is recommended in conjunction with the consumption rate control mechanism to avoid abnormal node resource utilization due to event backlog.)

Caution: Always ensure that the startSyncBlockNum parameter is configured correctly before restarting the node. A correctly configured node will synchronize historical events from the specified block height upon startup. Incorrect configuration can lead to duplicate or missed event pushes, thus affecting the correctness of the business logic.

Consumption Rate Awareness Mechanism

In the V1.0 framework, event data, once encapsulated, was directly pushed to the event queue for asynchronous consumption by the plugin. However, when a plugin’s consumption capacity was insufficient, event data could continuously accumulate in the memory, eventually leading to memory overflow problems.

To address this problem, V2.0 introduces a consumption rate awareness mechanism by adding a new plugin interface getPendingSize to query the number of pending events in the current event queue. Before loading new event data, the event service will call the getPendingSize interface to check the plugin’s current consumption status:

  • Return value > 50000 indicates that the plugin is in a busy state, and the event service will pause loading new event data to prevent continuous memory accumulation.
  • Return value <= 50000 indicates that the plugin has sufficient consumption capacity, and the event service will continue to push data.

This mechanism enables dynamic regulation between event loading and the plugin consumption capacity, effectively enhancing the system’s stability and robustness in high-concurrency processing and historical data synchronization scenarios.

Note: If you choose to use the V2.0 framework, we strongly recommend upgrading the event plugins to their latest versions (v2.1.0) to ensure compatibility with consumption rate control.

Version Notes

To ensure application developers have sufficient time for a smooth transition to the new version, the original V1.0 framework is still retained in Kant. We recommend that you gradually migrate to the V2.0 framework based on your specific needs.

The V1.0 framework will be completely removed in a future release when deemed appropriate, with only V2.0 retained. We strongly recommend that application developers plan for compatibility adaptation and version switching in advance.

The event service will default to V1.0 after the Kant version deployment. To enable V2.0, the switch can be made via the following configuration option:

event.subscribe.version = 1 // 1 means v2.0 , 0 means v1.0

Compatibility

The specific differences between the Event Service Framework V1.0 and V2.0 are as follows:

How to Migrate to the V2.0 Framework?

Key Considerations Before Migration

  • Application Dependency on Internal Transactions Subscription Feature
    The V2.0 framework does not support internal transaction log subscription. The internalTransactionList field in emitted TransactionLogTrigger events will be empty. Therefore, migration is not recommended at this time for applications that rely on internal transaction information. Please continue using the V1.0 framework until this feature is supported in a later version.
  • Plugin Version Compatibility
    To support the consumption rate awareness mechanism of V2.0, we strongly recommend upgrading to and using the event plugins’ latest versions (v2.1.0). This is especially important when synchronizing events from a specified block height, due to the potential for a large volume of event data. Insufficient plugin consumption capacity can lead to continuous memory growth or even memory leaks in the node.

Steps for Migration

1. Generating the New Event Plugin

Clone the event-plugin project from the GitHub repository and switch to the dedicated branch for the new plugin version. Then, execute the build command to generate the .zip file for the new plugin.

git clone git@github.com:tronprotocol/event-plugin.git
cd event-plugin
git checkout feature/new_event_service
./gradlew build

2. Enabling the V2.0 Framework via Configuration

In the FullNode configuration file, add the following configuration to enable the V2.0 framework:

event.subscribe.version = 1

3. Configuring Event Subscription

The V2.0 framework’s subscription configuration method remains consistent with V1.0; no additional modifications are required. Please refer to the event subscription configuration documentation for detailed configuration instructions.

4. (Optional) Synchronizing Historical Block Events

The V2.0 framework supports historical event synchronization starting from a specified block height. You can set the starting synchronization height using the following configuration:

event.subscribe.startSyncBlockNum = <block_height>

5. Starting the Node and Plugin

Upon completing the aforementioned configurations, start the FullNode and the corresponding event plugin to finalize the migration to the V2.0 framework. The node startup command is as follows:

java -jar FullNode.jar -c config.conf --es

Event Service Framework V2.0 was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Introduction of Cancun Compatible Features in TRON]]> https://medium.com/tronnetwork/introduction-of-cancun-compatible-features-in-tron-b84dff7ed6b8?source=rss----839d5c53e074---4 https://medium.com/p/b84dff7ed6b8 Tue, 29 Apr 2025 09:45:06 GMT 2025-04-30T01:51:53.017Z

Summary

The TRON network continues to evolve with significant upgrades to enhance its performance, security, and compatibility since its inception. One of the most notable recent advancements of the TRON Virtual Machine (TVM) is the compatibility upgrade with Ethereum’s Cancun, which introduces several new features while maintaining TRON’s core value proposition of high throughput and low transaction costs.

In March 2024, Ethereum officially launched its Dencun (Cancun-Deneb) upgrade, with the Cancun portion specifically bringing several critical virtual machine enhancements. To maintain compatibility with these new Ethereum features and to further expand TRON’s blockchain efficiency, interoperability, and ecosystem growth, we have introduced the Cancun upgrade functionality to the TRON network.

The TRON Virtual Machine (TVM) serves as the execution environment for smart contracts on the TRON blockchain, interpreting bytecode compiled from high-level languages like Solidity. With the Cancun upgrade, the TVM now supports the latest EVM opcodes and features, ensuring that developers can seamlessly port their Ethereum applications to TRON while benefiting from TRON’s unique advantages in terms of cost and speed.

In this article, we’ll delve into the technical aspects of the Cancun features in TRON, exploring its implementation details and the improvements it brings to the Java-Tron codebase, with a particular emphasis on the TVM enhancements.

Technical Foundations

1. TIP-745: Introduce EIP-4844 and EIP-7516 instructions

At the heart of the Cancun upgrade is EIP-4844, a protocol originally pioneered by Ethereum to optimize Layer 2 scalability.

EIP-4844 introduces a new transaction format for “blob-carrying transactions”, which contain a large amount of data and a new instruction BLOBHASH to get versioned hashes of blob transactions.

EIP-7516 introduces a new instruction that returns the value of the blob base-fee of the current block it is executing in.

Due to the different demands for L2 and data processing capabilities between TRON and Ethereum, we have not introduced blob-type transactions for the time being. And in view of this situation, the implementations of BLOBHASH and BLOBBASEFEE instructions differ from Ethereum.

It’s also important to note that this implementation currently focuses only on introducing the new instructions. Full blob transaction support and the point evaluation precompiled contract will be implemented in future versions. When we implement the point evaluation precompile, we will use an address different from Ethereum’s implementation (0x0a), as this address is already allocated to the ValidateMultiSign precompile on TRON. This phased approach allows us to carefully adapt Ethereum’s data availability solutions to TRON’s unique architecture while maintaining backward compatibility.

2. TIP-650: Implement EIP-1153 Transient storage opcodes

EIP-1153 introduces transient storage opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction.

3. TIP-651: Implement EIP-5656 MCOPY — Memory copying instruction

EIP-5656 introduces an efficient EVM instruction for copying memory areas.

4. TIP-652: Announce EIP-6049 Deprecate SELFDESTRUCT

EIP-7516 announces to deprecate SELFDESTRUCT by discouraging its use in Ethereum Shanghai upgrade and its behavior has been modified after the Ethereum Cancun upgrade. In accordance with the development plan of TRON, we declare the deprecation of the SELFDESTRUCT in this upgrade.

Overview of New TVM Instructions

Technical Interpretation

1. BLOBHASH instruction

  • Introduces a new instruction BLOBHASH (with opcode 0x49) and has an Energy cost of 3.
  • This opcode reads the index from the top of the stack and places a single item with the value 0 onto the stack.

2. BLOBBASEFEE instruction

  • Introduces a new instruction BLOBBASEFEE (with opcode 0x4a) and has an Energy cost of 2.
  • This opcode returns a single value 0.

3. Transient storage instructions

  • Introduces two new instructions TLOAD (with opcode 0x5c) and TSTORE (with opcode 0x5d), and has an Energy cost of 100 separately.
  • TLOAD opcode pops a 32-byte word from the top of the stack, uses this value as the address in transient storage, retrieves the corresponding 32-byte word from that address, and then pushes this value back onto the stack.
  • TSTORE opcode pops two 32-byte words from the top of the stack, using the first as the address in transient storage and the second as the value to be stored. It then saves this value at the corresponding location in transient storage.

4. Memory copy instruction

  • Introduces a new instruction MCOPY (with opcode 0x5e) and the Energy consumption for this operation is calculated as follows:
words_copied = (length + 31) // 32
g_verylow    = 3
g_copy       = 3 * words_copied + memory_expansion_cost
gas_cost     = g_verylow + g_copy
  • This opcode pops three 32-byte words from the top of the stack, which are the destination position, the source position, and the length of the memory copy. It returns no item on stack.

Contract Example

This is an example contract that includes all the new instructions mentioned above：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract CancunTest {

    constructor() payable {}

    receive() payable external {}

    // BLOBHASH example
    function testBlobHash(uint256 blobIndex) public view returns (bytes32) {
        bytes32 res = blobhash(blobIndex);
        require(res == bytes32(0), "BLOBHASH failed");
        return res;
    }

    // BLOBBASEFEE example
    function testBlobBaseFee() public view returns (uint256) {
        uint256 res = block.blobbasefee;
        require(res == 0, "BLOBBASEFEE failed");
        return res;
    }

    // transient storage (TSTORE/TLOAD) example
    function testTransientStorage(bytes32 value) public returns (bytes32) {
        bytes32 res = 0;
        assembly {
            res := tload(1)
        }
        require(res == bytes32(0), "TLOAD failed");

        assembly {
        // Store the value in transient storage slot 1
            tstore(1, value)
            res := tload(1)
        }
        require(res == value, "TSTORE failed");
        // Clear the transient storage at the end of the function
        assembly {
            tstore(1, 0)
        }
        return res;
    }

    // memory copy (MCOPY) example
    function testMemoryCopy(bytes32 data) public pure returns (bytes32) {
        bytes32 value;
        assembly {
            let memPtr := mload(0x40)
            mstore(memPtr, data)
            let memPtr2 := mload(0x40)
            mcopy(memPtr2, memPtr, 32)
            value := mload(memPtr2)
        }

        require(data == value, "Memory copy failed");
        return value;
    }

    function validateInputLengths(
        bytes calldata version,
        bytes calldata commitment,
        bytes calldata z,
        bytes calldata y,
        bytes calldata proof
    ) internal pure {
        require(version.length == 32, "Invalid versionhash length");
        require(commitment.length == 48, "Invalid commitment length");
        require(z.length == 32, "Invalid evaluation point length");
        require(y.length == 32, "Invalid claimed value length");
        require(proof.length == 48, "Invalid proof length");
    }
}

Impact

The TRON implementation of Ethereum Cancun upgrade delivers substantial benefits by creating a powerful synergy between technical advancement and practical utility for its ecosystem participants.

For developers, these new features bring numerous advantages. For example, the introduction of transient storage opcodes significantly reduces gas costs for complex operations that previously required expensive storage manipulations, enabling the development of more sophisticated and cost-effective smart contracts. Additionally, the MCOPY instruction dramatically improves the efficiency of memory operations, allowing for optimized contract execution.

With the implementation of these EVM-compatible features, developers can now seamlessly port their Ethereum applications to TRON with minimal modifications. This cross-chain compatibility effectively expands the potential user base for dApps while leveraging TRON’s inherent advantages in throughput and cost-effectiveness.

Conclusion

This article has provided a comprehensive technical and practical examination of TRON’s Ethereum Cancun compatibility upgrade. We’ve explored the key technical implementations including enhanced VM compatibility and functional changes based on TRON’s characteristics. The Cancun upgrade marks a crucial milestone in TRON’s development, aligning it more closely with Ethereum’s capabilities while preserving TRON’s distinctive advantages in efficiency and cost.

For more information

GitHub: https://github.com/tronprotocol
Telegram: https://t.me/troncoredevscommunity

Introduction of Cancun Compatible Features in TRON was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Mainnet Kant Announcement]]> https://medium.com/tronnetwork/mainnet-kant-announcement-03022cb70350?source=rss----839d5c53e074---4 https://medium.com/p/03022cb70350 Tue, 29 Apr 2025 09:43:04 GMT 2025-04-29T09:41:59.244Z

The TRON network is preparing to release the GreatVoyage-v4.8.0 (Kant) version (hereafter referred to as “Kant” or the “Kant version”). This is a mandatory upgrade that introduces several key updates and governance proposals. Please find the details below.

New Features

Ethereum Cancun Upgrade Support

1. TIP-650: Implement EIP-1153 Transient Storage Instructions

The TRON Virtual Machine (TVM) will support the TLOAD and TSTORE opcodes, aligning with the Ethereum Cancun upgrade.

Transient storage is a temporary storage mechanism between persistent storage (storage) and memory. It offers a more gas-efficient storage solution that persists for the duration of a transaction. Data in transient storage is automatically cleared upon transaction completion.

Note: This feature is governed by TRON network parameter #83. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

2. TIP-651: Implement EIP-5656 MCOPY — Memory Copying Instruction

TVM will support the MCOPY instruction, aligning with the Ethereum Cancun upgrade.

Memory copying is an operation that copies data from its original location to a target location in memory. It aims to reduce resource costs for memory area copying, thereby improving copying efficiency.

Note: This feature is governed by TRON network parameter #83. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

3. TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction

TVM will support the Ethereum Cancun upgrade’s BLOBHASH and BLOBBASEFEE instructions:

The BLOBHASH and BLOBBASEFEE instructions are associated with Ethereum Blob transactions. Currently, BLOBHASH and BLOBBASEFEE are implemented as stubs, both returning 0. The precompiled contracts verifying Zero-knowledge Proof (ZKP) are not implemented in Kant since blob transactions are not supported.

Note: This feature is governed by TRON network parameter #89. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

Core

1. Enhanced Consensus Layer Verification

1.1 TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer

Prior to Kant, transaction validation was optimized at various points, but only focused on the transaction broadcast phase. The Kant version enhances transaction validation at the consensus layer, further improving transaction processing consistency and validity.

  • Strengthened Account Creation Transaction Size Check: Verifies that the transaction size, excluding its results and signatures, does not exceed the maximum byte limit allowed for account creation transactions (parameter #82).
  • Enhanced Transaction Size Validation: Verifies whether the transaction body content exceeds the size limit.
  • Transaction Result List Constraint: Ensures consistency with the contract count (currently limited to 1).
  • Transaction Expiration Time Check: Verifies that the transaction expiration time is later than the next block’s slot time.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.2 Enhanced Validation of Block Production during Maintenance Periods

Maintenance periods are designated for Super Representative (SR) elections and proposal processing. Therefore, SRs must not produce blocks during these periods. However, in prior versions, blocks produced by SRs during maintenance periods could potentially pass validation. The Kant version modifies block production and validation logic to prevent SRs from producing blocks during maintenance periods. Any block produced during this time will fail validation.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.3 Enhanced Block Header Validation

Block time, recorded in the block header, represents the time a block is produced. Given that the TRON network’s block slot time is 3 seconds, the block time must be a strict multiple of 3 seconds.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.4 Optimized Super Representative Election Ranking Algorithm

In versions prior to Kant, when multiple SRs had identical vote counts, the system determined the ranking order based on the hash of the SR’s address. However, due to the risk of hash collisions and the potential for impacting ranking performance in extreme cases, the Kant version optimizes the SR ranking rules by implementing a more intuitive and stable lexicographical ordering of addresses (i.e., ranking by address alphanumerically). This approach eliminates hash collision-related performance issues and provides a more transparent and predictable ranking mechanism.

TVM

1. TIP-652: Deprecation of the SELFDESTRUCT Instruction

Note: TIP-652 itself does not change how the SELFDESTRUCT instruction currently works, however, it officially announces that client developers will modify its behavior in future upgrades. Therefore, applications that expose SELFDESTRUCT to users should strongly warn them about the incoming semantic changes.

Net

1. Optimized Block Synchronization Logic

Kant introduces two key optimizations to the block synchronization logic, significantly improving synchronization efficiency:

1.1 Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth

Kant optimizes the synchronization request mechanism by eliminating requests for solidified block data from remote nodes. This prevents redundant requests for existing data, reduces resource waste, and improves synchronization efficiency.

1.2 Faster Block Synchronization Task Scheduling for Enhanced Efficiency

Kant adjusts the scheduling frequency of block synchronization tasks from once per second to once per 100 milliseconds. This accelerates block processing, further improving block synchronization efficiency.

2. Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions

Kant strengthens transaction validity verification. Upon receiving a transaction message, the node will discard transactions with zero contracts and disconnect from the sender.

Other Changes

1. Enhanced Event Service Framework (V2.0) Provision

The previous event service framework (V1.0) lacked support for processing events in historical blocks and coupled event processing tightly with block processing logic. Consequently, event service exceptions could lead to block processing failures, disrupting block broadcast and synchronization.

Kant introduces a new event service framework (V2.0) that decouples event services from block processing at the thread level. This prevents node disruptions caused by event service exceptions. V2.0 also supports event processing that begins from local historical blocks. Users can specify the starting block height for event synchronization using the event.subscribe.startSyncBlockNum configuration parameter. This feature is disabled if the parameter value is ≤ 0, and enabled otherwise.

Note: Double-check the startSyncBlockNum configuration when restarting the node, since the node will synchronize historical events from the specified block height upon startup.

The original event service framework is retained to facilitate a gradual migration to the new framework. Post-Kant deployment, the V1.0 version remains the default. To utilize the V2.0 version, modify the following configuration parameter:

event.subscribe.version = 1 // 1 means v2.0 , 0 means v1.0

2. Cross-Platform Consistent java.lang.strictMath Replacement for java.lang.math

The mathematical operation library is migrated from java.lang.Math to java.lang.StrictMath, to further enhance Java-tron’s cross-platform compatibility and establish a robust foundation for future support of diverse hardware architectures (including ARM). This ensures consistent computational results across different platforms.

3. Optimized Node Exit and Startup Logic

3.1 Optimized Node Exit Logic

Kant standardizes the code logic for process termination while preserving original functionalities, enhancing code consistency and system stability.

3.2 Optimized Node Startup Logic

Kant introduces enhanced service integrity checks for the node startup process. To ensure operational stability, the node will immediately terminate if any core service (including API, P2P, Prometheus, and event plugins) fails to initialize. This prevents operation with incomplete critical services.

Additionally, the Kant version extends the API service with the following four configurable options (all enabled by default), providing node deployers the choice to selectively disable or enable these API service features:

node.rpc.enable = true
node.rpc.solidityEnable = true
node.rpc.PBFTEnable = true
node.http.PBFTEnable = true

4. Dependency Library Security Upgrade

To enhance system security, Kant has updated several underlying dependency libraries and removed obsolete components. This includes updating the jcommander, pf4j, grpc, logback, and libp2p dependency libraries to secure and stable releases, and removing the deprecated library quartz for task scheduling.

5. Gradle 7.6.4 Upgrade with Dependency Integrity Verification

Kant upgrades Gradle to version 7.6.4 and enables security verification of third-party dependency JAR packages. During JAR file packaging and generation, the system automatically validates all referenced external dependencies to ensure they originate from trusted sources and are free from tampering. This prevents the inclusion of potentially vulnerable JAR packages in the final product. This enhancement effectively mitigates supply chain attacks and bolsters the overall build security of the project.

6. Null Pointer Exception Fix During Startup

Kant resolves an intermittent null pointer exception that could occur during node startup. This ensures the consensus service initializes before the network service, preventing startup failures.

7. Internal Transaction Details Logging for CANCELALLUNFREEZEV2 Opcode

Nodes configured to save internal transactions, beginning with the Kant version, will log the unstaking amounts of various resources when processing transactions that include the CANCELALLUNFREEZEV2 opcode. For example: {“BANDWIDTH”:100,”ENERGY”:100,”TRON_POWER”:0}.

API

1. Enhanced Compatibility for Ethereum JSON-RPC Interface

1.1 Support for Querying Solidified Data via finalized Block Parameter in JSON-RPC API

Kant’s JSON-RPC interface now supports the “finalized” parameter. This allows certain interfaces that use a block number as a parameter to accept “finalized” for querying the latest solidified block information, further improving compatibility with the Ethereum JSON-RPC interface.

Interfaces supporting “finalized” as a parameter:

  • eth_getBlockTransactionCountByNumber
  • eth_getBlockByNumber
  • eth_getTransactionByBlockNumberAndIndex
  • eth_getLogs

Interfaces not supporting “finalized” as a parameter:

1.2 New Limits on Block Range and “Topics” Quantity for JSON-RPC Log Queries

Kant introduces a query limit mechanism for JSON-RPC event query interfaces, controlled by the following two configuration parameters:

  • maxBlockRange: Specifies the maximum block range allowed for log queries. The default value is 5000. The range between the starting block and the ending block cannot exceed this value when related interfaces are called.
  • maxSubTopics: Limits the maximum number of “sub topics” that can be set. The default value is 1000, meaning that a maximum of 1000 “sub topics” can be set during interface calls.

Note: The values of the above configuration parameters must be positive integers greater than 0. If a configured value is less than or equal to 0, the corresponding limit is considered disabled, and the relevant interfaces will not perform this validation.

node.jsonrpc.maxBlockRange = 5000
node.jsonrpc.maxSubTopics = 1000

Interfaces supporting maxBlockRange:

  • eth_getLogs

Interfaces supporting maxSubTopics:

1.3 Optimized eth_getLogs to Resolve Data Retrieval Issue in Rare Hash Collisions

Kant optimizes the eth_getLogs processing logic to resolve the issue where the interface failed to retrieve data in rare hash collision scenarios, thus increasing interface stability.

2. Non-Null Payment Address Validation in Shielded Transaction Creation API

Kant adds validation to the shielded transaction creation API to ensure a payment address is not empty. If the validation fails, the API returns the reason for the failure, improving the user experience.

Science is organized knowledge. Wisdom is organized life. — Immanuel Kant

Mainnet Kant Announcement was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Gas Optimization Guide for Smart Contracts]]> https://medium.com/tronnetwork/smart-contract-gas-optimization-guide-22958db86ccb?source=rss----839d5c53e074---4 https://medium.com/p/22958db86ccb Tue, 01 Apr 2025 09:53:36 GMT 2025-04-02T04:24:02.196Z

Effectively managing gas consumption is a critical aspect of smart contract development. This guide explores techniques and practical strategies for optimizing gas consumption, helping developers minimize costs and improve efficiency on the TRON blockchain.

1. Optimization on Variables and Storage Arrangement

1.1 Reduce State Variable Usage

State variables are stored on-chain and therefore require Energy for every modification.

Define variables that are required only for function execution as memory variables or temporary variables on the stack to reduce Energy consumption caused by read/write (R/W) operations on state variables.

1.2 Arrange Storage based on Variable Types and Sizes

In theory, Solidity variables like unit8 and unit16 can consume less storage when packed. However, when used as individual variables, they occupy almost the same storage slot size as a unit256 variable.

Therefore, packing multiple smaller variable types into a single slot can effectively save storage space. For example, you can pack multiple unit128 and uint64 variables into the same slot following the “Place variables of the same type together in a wide-to-narrow sequence” principle.

1.3 Constant and Immutable Variables

Constant Variable: This type of variables is determined during compilation, embedded within the bytecode, and remains immutable post-deployment. Reading constants does not consume additional energy associated with storage retrieval.

uint256 constant FEE_RATE = 10;

Immutable Variable: This type of variables can be configured in construction functions and stay immutable once the contract is deployed. Immutable variables occupy less storage space than regular state variables, and reading immutable variables does not consume additional energy associated with storage retrieval.

uint256 immutable START_TIME;

constructor(uint256 _start) {
    START_TIME = _start;
}

Set variables that should remain unchanged to constant or immutable to minimize reading consumption.

1.4 Reduce Redundant Reads of Variables

In Solidity, each read operation on state variables consumes Energy. To optimize, assign the value to a local variable (stored on the stack or in memory) and reuse this local variable in your logic to minimize redundant state reads.

uint256 value = stateVar; 
// For later operations, keep using `value` instead of `stateVar`

2. Optimization on Logic and Function Calls

2.1 Short-Circuit

In the case of conditional statements, such as if or require, arrange boolean expressions so that conditions that are most likely false/true are placed first to shorten the execution.

// Assume that conditionA is more likely to be false
require(conditionA && conditionB, "Failed");
// When A is false, the fail result is returned. The computation on B is bypassed.

2.2 Minimize Redundant Operations in Loops

In loops (e.g., for/while), if complex logics or R/W operations on state variables are involved, Energy consumption can soar with each iteration.

Where feasible, limit the number of loop iterations to an acceptable range or reduce the cost per iteration through batched operations and Events.

When accessing state variables within a loop, it is advisable to retrieve them once before the loop, store and modify them in memory variables during the loop, and then write the final values back to state storage after the loop completes.

2.3 Minimize Function Call Depth

Function calls themselves incur invocation gas costs. Inlining simple logic can reduce Energy consumption to some extent, but readability and maintainability must also be carefully considered.

Internal vs. Public/External Functions: Internal function calls typically incur lower costs than external function calls. Therefore, declare functions that are used exclusively within a contract as internal.

2.4 Use calldata instead of memory

Declare external function parameters that are only read within the function body as calldata to minimize copy operations and therefore reduce Energy costs for memory allocation.

function processData(uint256[] calldata data) external {
    // Here, `data` is stored as calldata instead of memory
}

3. Optimization on Data Structures and Access Methods

3.1 Choose Suitable Data Structures

Mapping vs. Array: If the data can be queried by key instead of traversal, mappings are generally more efficient than arrays. However, if extensive data traversal is required, arrays allow sequential access, whereas mappings cannot be directly traversed.

Static vs. Dynamic Array: Static arrays consume less storage and Energy resources. However, the choice of array types should be based on your business requirements.

3.2 Minimize Storage Operations

If massive R/W operations to storage are needed within a contract, load the data in memory or the stack before the logic starts, and write the results to storage once processing is complete.

Implicit R/W operations can occur in the function body if reference types (e.g., dynamic arrays or structs) are conveyed as function parameters. In this case, determine whether to declare the reference types as memory or storage.

3.3 Use Events for Some Storage Scenarios

Data that only needs to be recorded or tracked can be covered in events for logging instead of being stored on-chain, especially for data not required by the contract logic in the following procedure. This method can dramatically cut storage costs.

For example, for a batch of user activity results, as long as these results are not required for later determinations in the smart contract, using events can reduce massive Energy consumption.

4. Advanced Optimization Methods

4.1 Inline Assembly

In scenarios where extremely high performance and massive Energy resources are required, assembly can be used to optimize logics such as batch processing, mathematical operations, or direct operations on storage slots.

However, readability, maintainability, and security must be prioritized, and developers should have a comprehensive understanding of the underlying logic of the Ethereum Virtual Machine (EVM).

4.2 Use Libraries instead of Inheritance or Repetition

This applies to features or modules that are generally and frequently called. Using libraries can reduce function duplication and minimize bytecode size.

However, costs of deploying and calling the libraries should be evaluated according to your actual needs.

4.3 Manage Contract Sizes

For contract deployment, the larger the bytecode size, the higher the Energy consumption. If a contract contains excessively redundant logic or resources, you can split the contract or use libraries to keep the contract in a smaller size.

For an enormously large contract, you can use upgradeable or proxy patterns to partition the logic into multiple segments for deployment, thereby reducing the size of individual contracts.

4.4 Moderate Use of Proxy to Reduce Energy Consumption of Application Iterations

If your application requirements change frequently, adopting an upgradable proxy pattern allows you to retain data and avoid redeploying massive logic code, thereby minimizing the cost of redeployment.

In this case, the storage layout must be carefully designed to prevent conflicts or disorders during upgrades.

Gas Optimization Guide for Smart Contracts was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>