├── Archive ├── Democritus └── mainnet.md ├── LICENSE ├── Mainnet Upgrade Archive ├── GreatVoyage-v4.7.4(Bias) │ └── mainnet.md └── GreatVoyage-v4.8.0(Kant) │ └── mainnet.md ├── README.md ├── SR Meetings ├── SR Meeting 02.md ├── SR Meeting 03.md ├── SR Meeting 04.md ├── SR Meeting 05.md └── SR Meeting 06.md └── TRON Core Devs Meetings ├── Meeting 01.md ├── Meeting 02.md ├── Meeting 03.md ├── Meeting 04.md ├── Meeting 05.md ├── Meeting 06.md ├── Meeting 07.md ├── Meeting 08.md ├── Meeting 09.md ├── Meeting 10.md ├── Meeting 11.md ├── Meeting 12.md ├── Meeting 13.md ├── Meeting 14.md ├── Meeting 15.md ├── Meeting 16.md ├── Meeting 17.md ├── Meeting 18.md ├── Meeting 19.md ├── Meeting 20.md ├── Meeting 21.md ├── Meeting 22.md ├── Meeting 23.md ├── Meeting 24.md ├── Meeting 25.md ├── Meeting 26.md ├── Meeting 27.md ├── Meeting 28.md ├── Meeting 29.md ├── Meeting 30.md ├── Meeting 31.md ├── Meeting 32.md ├── Meeting 33.md ├── Meeting 34.md ├── Meeting 35.md ├── Meeting 36.md ├── Meeting 37.md ├── Meeting 38.md ├── Meeting 39.md ├── Meeting Template.md ├── README.md ├── Wallet Devs Meeting 01.md └── Wallet Devs Meeting 02.md /Archive: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /Democritus/mainnet.md: -------------------------------------------------------------------------------- 1 | # Mainnet Tasks 2 | 3 | This document outlines the mainnet tasks that need to be completed to make Democritus ready for Mainnet launch. **Last updated June 4, 2025.** 4 | 5 | Note: The target version number of Democritus is v4.8.1 . 6 | 7 | 8 | ## Table of contents 9 | 10 | - [The main content of the release](#Release-included-in-the-Network-Upgrade.) 11 | - [Implementation Progresss](#Implementation-Progresss) 12 | - [Network Status](#Network-Status) 13 | 14 | 15 | 16 | ## The main content of the release 17 | 18 | This section summarizes all the details of Democritus's releases. and all the content will be disccussed in the core devs meeting. 19 | 20 | Note: The following tags are used to indicate the status of each item. 21 | - [x] Indicates that the tiem has been developed and is in the final state. 22 | - [ ] Indicates that the implementation work is ongoing. 23 | 24 | #### New Features 25 | 26 | TBD 27 | 28 | ## Implementation Progresss 29 | 30 | Implementation status of Included TIPs in java-tron. 31 | 32 | TIP | | | | | | | 33 | |----------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|--------------|--------| 34 | | **Java-tron** | | | | | | 35 | 36 | ### Readiness Checklist 37 | 38 | **List of outstanding items before deployment.** 39 | 40 | 41 | 42 | - Deploy Clients 43 | - [ ] Java-tron v4.8.1 44 | 45 | 46 | ## Network Status 47 | 48 | ### Network Upgrade Plan 49 | 50 | Estimated Nile upgrade time: (TBD) 51 | 52 | - [ ] Notify the community to upgrade (TBD) 53 | - [ ] Follow up to remind the community to complete the upgrade (TBD) 54 | 55 | Estimated mainnet upgrade time: (TBD) 56 | 57 | - [ ] Notify the community, SRs, CEX, Wallets, DEX, etc.to upgrade (TBD) 58 | - [ ] Follow up the upgrade status and progress closely (Contact project team every week, record the upgrade progress) 59 | - [ ] Ensure the SRs, CEX, Wallets to complete (TBD) 60 | 61 | Estimated Shasta upgrade time: (TBD) 62 | 63 | - [ ] Notify the community to upgrade (TBD) 64 | 65 | ### Proposals Plan(Fork Plan) 66 | 67 | TBD 68 | 69 | ### Network Upgrade and Fork Status 70 | 71 | | Network | Github | Kant Release Date | Latest Status | Fork | 72 | |---------|------------|-----|-----|-----| 73 | | [Nile](https://nileex.io/) | https://github.com/tron-nile-testnet/nile-testnet | | | | 74 | | [Mainnet](https://tron.network/) |https://github.com/tronprotocol/java-tron | | | | 75 | | [Shasta](https://www.trongrid.io/shasta) | https://github.com/tronprotocol/java-tron | | | | 76 | 77 | Nile Upgrade Instruction: https://nileex.io/run/getRunPage 78 | 79 | Mainnet/Shasta Upgrade Instruction： https://tronprotocol.github.io/documentation-en/releases/upgrade-instruction 80 | 81 | 82 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /Mainnet Upgrade Archive/GreatVoyage-v4.7.4(Bias)/mainnet.md: -------------------------------------------------------------------------------- 1 | ## Bias Network Upgrade Specification 2 | 3 | ### Included TIPs 4 | Changes included in the Network Upgrade. 5 | 6 | * [TIP-621: Add code version column to HelloMessage](https://github.com/tronprotocol/tips/issues/621) 7 | * [TIP-635: Optimize Reward Withdrawal To Improve TPS](https://github.com/tronprotocol/tips/issues/635) 8 | * [Adding gRPC reflection service to support interactive command line tools such as `gRPCurl`.](https://github.com/tronprotocol/java-tron/issues/5391) 9 | * [Module dependency refactor: unified the duplicate dependencies to common module.](https://github.com/tronprotocol/java-tron/issues/5561) 10 | * [Removing Lite FullNode Tool from frameworkModule.](https://github.com/tronprotocol/java-tron/issues/5489) 11 | * [Stop broadcasting transactions when the block cannot be solidified](https://github.com/tronprotocol/java-tron/issues/5562) 12 | 13 | ### Upgrade Schedule 14 | 15 | | Network | Date | 16 | |---------|------------| 17 | | Nile | 03/14/2024 | 18 | | Shasta | 03/28/2024 | 19 | | Mainnet | 03/25/2024| 20 | 21 | ### Implementation Progresss 22 | 23 | Implementation status of Included TIPs in java-tron. 24 | 25 | TIP | [TIP-621](https://github.com/tronprotocol/tips/issues/621) | [TIP-635](https://github.com/tronprotocol/tips/issues/635) | Adding gRPC reflection service to support interactive command line tools such as `gRPCurl` | Module dependency refactor: unified the duplicate dependencies to common module | Removing Lite FullNode Tool from frameworkModule | Stop broadcasting transactions when the block cannot be solidified | 26 | |----------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|--------------|--------| 27 | | **Java-tron** | [Merged](https://github.com/tronprotocol/java-tron/pull/5584) | [Merged](https://github.com/tronprotocol/java-tron/pull/5406) + [Merged](https://github.com/tronprotocol/java-tron/pull/5654) + [Merged](https://github.com/tronprotocol/java-tron/pull/5683) | [Merged](https://github.com/tronprotocol/java-tron/pull/5643)+[Merged](https://github.com/tronprotocol/java-tron/pull/5751) | [Merged](https://github.com/tronprotocol/java-tron/pull/5625)+[Merged](https://github.com/tronprotocol/java-tron/pull/5689) | [Merged](https://github.com/tronprotocol/java-tron/pull/5650) | [Merged](https://github.com/tronprotocol/java-tron/pull/5643)+[Merged](https://github.com/tronprotocol/java-tron/pull/5751) 28 | 29 | ### Readiness Checklist 30 | 31 | **List of outstanding items before deployment.** 32 | 33 | 34 | 35 | - Deploy Clients 36 | - [x] Java-tron v4.7.4 37 | - SDK & Tools 38 | - [x] Tronweb 39 | - [x] Trident 40 | - [x] Tron IDE 41 | - [x] TronBox 42 | - [x] wallet-cli 43 | - [x] TronScan Nile 44 | 45 | -------------------------------------------------------------------------------- /Mainnet Upgrade Archive/GreatVoyage-v4.8.0(Kant)/mainnet.md: -------------------------------------------------------------------------------- 1 | # Mainnet Tasks 2 | 3 | This document outlines the mainnet tasks that need to be completed to make Kant ready for Mainnet launch. **Last updated Jun 4, 2025.** 4 | 5 | Note: The target version number of Kant is v4.8.0 . 6 | 7 | 8 | ## Table of contents 9 | 10 | - [The main content of the release](#Release-included-in-the-Network-Upgrade.) 11 | - [Implementation Progresss](#Implementation-Progresss) 12 | - [Network Status](#Network-Status) 13 | 14 | 15 | 16 | ## The main content of the release 17 | 18 | This section summarizes all the details of Kant's releases. and all the content was disccussed in the [No.35 core devs meeting](https://github.com/tronprotocol/pm/issues/121), check detail meeting notes [here](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2035.md). 19 | 20 | Note: The following tags are used to indicate the status of each item. 21 | - [x] Indicates that the item has been developed and is in the final state. 22 | - [ ] Indicates that the implementation work is ongoing. 23 | 24 | #### New Features 25 | 26 | - [x] **Ethereum Cancun Upgrade Support** 27 | - [x] [TIP-650: Implement EIP-1153 Transient Storage Instructions](https://github.com/tronprotocol/tips/blob/master/tip-650.md ), see [PR#6185](https://github.com/tronprotocol/java-tron/pull/6185), [PR#6195](https://github.com/tronprotocol/java-tron/pull/6195), [PR#6214](https://github.com/tronprotocol/java-tron/pull/6214) 28 | - [x] [TIP-651: Implement EIP-5656 MCOPY - Memory Copying Instruction](https://github.com/tronprotocol/tips/blob/master/tip-651.md), see [PR#6185](https://github.com/tronprotocol/java-tron/pull/6185), [PR#6194](https://github.com/tronprotocol/java-tron/pull/6194) 29 | - [x] [TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction](https://github.com/tronprotocol/tips/blob/master/tip-745.md ), see [PR#6232](https://github.com/tronprotocol/java-tron/pull/6232), [PR#6247](https://github.com/tronprotocol/java-tron/pull/6247), [PR#6270](https://github.com/tronprotocol/java-tron/pull/6270), [PR#6283](https://github.com/tronprotocol/java-tron/pull/6283) 30 | 31 | #### Core 32 | - [x] **Enhanced Consensus Layer Verification** 33 | - [x] [TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer](https://github.com/tronprotocol/tips/blob/master/tip-694.md ), see [PR#6172](https://github.com/tronprotocol/java-tron/pull/6172), [PR#6221](https://github.com/tronprotocol/java-tron/pull/6221) 34 | - [x] Enhanced Validation of Block Production during Maintenance Periods, see [PR#6187](https://github.com/tronprotocol/java-tron/pull/6187) 35 | - [x] Enhanced Block Header Validation, see [PR#6186](https://github.com/tronprotocol/java-tron/pull/6186 ) 36 | - [x] Optimized Super Representative Election Ranking Algorithm, see [PR#6173](https://github.com/tronprotocol/java-tron/pull/6173 ) 37 | 38 | #### Net 39 | - [x] **Optimized Block Synchronization Logic** 40 | - [x] Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth, see [PR#6184](https://github.com/tronprotocol/java-tron/pull/6184 ) 41 | - [x] Faster Block Synchronization Task Scheduling for Enhanced Efficiency, see [PR#6183](https://github.com/tronprotocol/java-tron/pull/6183) 42 | 43 | - [x] **Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions**, see [PR#6181](https://github.com/tronprotocol/java-tron/pull/6181) 44 | 45 | #### Other Changes 46 | - [x] **Enhanced Event Service Framework (V2.0) Provision**, see [PR#6192](https://github.com/tronprotocol/java-tron/issues/6192), [PR#6206](https://github.com/tronprotocol/java-tron/issues/6206), [PR#6223](https://github.com/tronprotocol/java-tron/issues/6223), [PR#6227](https://github.com/tronprotocol/java-tron/issues/6227), [PR#6234](https://github.com/tronprotocol/java-tron/issues/6234), [PR#6245](https://github.com/tronprotocol/java-tron/issues/6245), [PR#6256](https://github.com/tronprotocol/java-tron/issues/6256) 47 | - [x] [TIP-697: Cross-Platform Consistent java.strictMath Replacement for java.math](https://github.com/tronprotocol/tips/blob/master/tip-697.md), see [PR#6182](https://github.com/tronprotocol/java-tron/pull/6182), [PR#6210](https://github.com/tronprotocol/java-tron/pull/6210) 48 | - [x] **Optimized Node Exit and Startup Logic** 49 | - [x] Optimized Node Exit Logic, see [PR#6170](https://github.com/tronprotocol/java-tron/pull/6170), [PR#6177](https://github.com/tronprotocol/java-tron/pull/6177), [PR#6205](https://github.com/tronprotocol/java-tron/pull/6205) 50 | - [x] Optimized Node Startup Logic, see [PR#5857](https://github.com/tronprotocol/java-tron/pull/5857), [PR#6228](https://github.com/tronprotocol/java-tron/pull/6228), [PR#6233](https://github.com/tronprotocol/java-tron/pull/6233) 51 | - [x] **Dependency Library Security Upgrade**, see [PR#6180](https://github.com/tronprotocol/java-tron/pull/6180), [PR#6207](https://github.com/tronprotocol/java-tron/pull/6207), [PR#6257](https://github.com/tronprotocol/java-tron/pull/6257) 52 | - [x] **Gradle 7.6.4 Upgrade with Dependency Integrity Verification**, see [PR#5869](https://github.com/tronprotocol/java-tron/pull/5869), [PR#5903](https://github.com/tronprotocol/java-tron/pull/5903), [PR#6229](https://github.com/tronprotocol/java-tron/pull/6229) 53 | - [x] **Null Pointer Exception Fix During Startup**, see [PR#6216](https://github.com/tronprotocol/java-tron/pull/6216) 54 | - [x] **Internal Transaction Details Logging for CANCELALLUNFREEZEV2 Opcode**,see [PR#6191](https://github.com/tronprotocol/java-tron/pull/6191) 55 | 56 | #### API 57 | - [x] **Enhanced Compatibility for Ethereum JSON-RPC Interface** 58 | - [x] Support for Querying Solidified Data via finalized Block Parameter in JSON-RPC API, see [PR#6007](https://github.com/tronprotocol/java-tron/pull/6007), [PR#6238](https://github.com/tronprotocol/java-tron/pull/6238), [PR#6239](https://github.com/tronprotocol/java-tron/pull/6239) 59 | - [x] New Limits on Block Range and “Topics” Quantity for JSON-RPC Log Queries 60 | - [x] Optimized eth_getLogs to Resolve Data Retrieval Issue in Rare Hash Collisions, see [PR#6203](https://github.com/tronprotocol/java-tron/pull/6203) 61 | - [x] **Non-Null Payment Address Validation in Shielded Transaction Creation API**, see [PR#6174](https://github.com/tronprotocol/java-tron/pull/6174) 62 | 63 | ## Implementation Progresss 64 | 65 | Implementation status of Included TIPs in java-tron. 66 | 67 | TIP | [TIP-650](https://github.com/tronprotocol/tips/blob/master/tip-650.md) | [TIP-651](https://github.com/tronprotocol/tips/blob/master/tip-651.md) | [TIP-694](https://github.com/tronprotocol/tips/blob/master/tip-694.md) | [TIP-697](https://github.com/tronprotocol/tips/blob/master/tip-697.md) | [TIP-745](https://github.com/tronprotocol/tips/blob/master/tip-745.md) | Enhanced Event Service Framework (V2.0) Provision | 68 | |----------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|--------------|--------| 69 | | **Java-tron** | [Merged](https://github.com/tronprotocol/java-tron/pull/6185) + [Merged](https://github.com/tronprotocol/java-tron/pull/6195) + [Merged](https://github.com/tronprotocol/java-tron/pull/6214) | [Merged](https://github.com/tronprotocol/java-tron/pull/6185) + [Merged](https://github.com/tronprotocol/java-tron/pull/6194) | [Merged](https://github.com/tronprotocol/java-tron/pull/6172) + [Merged](https://github.com/tronprotocol/java-tron/pull/6221) | [Merged](https://github.com/tronprotocol/java-tron/pull/6182) + [Merged](https://github.com/tronprotocol/java-tron/pull/6210) | [Merged](https://github.com/tronprotocol/java-tron/pull/6232) + [Merged](https://github.com/tronprotocol/java-tron/pull/6247) + [Merged](https://github.com/tronprotocol/java-tron/pull/6270) + [Merged](https://github.com/tronprotocol/java-tron/pull/6283) | [Merged](https://github.com/tronprotocol/java-tron/pull/6256) + [Merged](https://github.com/tronprotocol/java-tron/pull/6245) + [Merged](https://github.com/tronprotocol/java-tron/pull/6234) + [Merged](https://github.com/tronprotocol/java-tron/pull/6227) + [Merged](https://github.com/tronprotocol/java-tron/pull/6223) + [Merged](https://github.com/tronprotocol/java-tron/pull/6206) + [Merged](https://github.com/tronprotocol/java-tron/pull/6192) 70 | 71 | ### Readiness Checklist 72 | 73 | **List of outstanding items before deployment.** 74 | 75 | 76 | 77 | - Deploy Clients 78 | - [x] Java-tron v4.8.0 79 | 80 | 81 | ## Network Status 82 | 83 | ### Network Upgrade Plan 84 | 85 | Estimated Nile upgrade time: about 15 days (2025.03.14 ~ 2025.03.31) 86 | 87 | - [x] Notify the community to upgrade (2025.03.15) 88 | - [x] Follow up to remind the community to complete the upgrade (2025.03.17) 89 | 90 | Estimated mainnet upgrade time: about 30 days (2025.04.29 ~ 2025.05.31) 91 | 92 | - [x] Notify the community, SRs, CEX, Wallets, DEX, etc.to upgrade (2025.05.01 ~ 2025.05.02) 93 | - [x] Follow up the upgrade status and progress closely (Contact project team every week, record the upgrade progress) 94 | - [x] Ensure the SRs, CEX, Wallets to complete before 2025.05.31 (Give feedbacks in time) 95 | 96 | Estimated Shasta upgrade time: about 7 days (2025.06.03 ~ 2025.06.10) 97 | 98 | - [ ] Notify the community to upgrade (2025.06.03 ~ 2025.06.10) 99 | 100 | ### Proposals Plan(Fork Plan) 101 | 102 | The Kant version has introduced 3 network parameters: 103 | - No.83 network parameter to enable the `TLOAD` `TSTORE` and `MCOPY` instructions, aligning with the Ethereum Cancun upgrade ([TIP-650](https://github.com/tronprotocol/tips/blob/master/tip-650.md ), and [TIP-651](https://github.com/tronprotocol/tips/blob/master/tip-651.md)). 104 | - No.88 network parameter to enable the verification of transaction limitations at consensus layer ([TIP-694](https://github.com/tronprotocol/tips/blob/master/tip-694.md )). 105 | - No.89 network parameter to enable the introduction of `BLOBHASH` and `BLOBBASEFEE` introductions to support the Ethereum Cancun upgrade ([TIP-745](https://github.com/tronprotocol/tips/blob/master/tip-745.md )). 106 | 107 | A draft plan is listed here, and it will be updated after the mainnet upgrade status is reviewed around 2025.05.31: 108 | - [x] Start proposals discussing on GitHub (around 2025.06.01 ~ 06.05) 109 | - [ ] Invite community devs and projects participate (2025.06.07 ~ 06.28) 110 | - [ ] Community and SRs review and decide the voting date according to the progress (around 2025.06.14 ~ 06.21) 111 | 112 | ### Network Upgrade and Fork Status 113 | 114 | | Network | Github | Kant Release Date | Latest Status | Fork | 115 | |---------|------------|-----|-----|-----| 116 | | [Nile](https://nileex.io/) | https://github.com/tron-nile-testnet/nile-testnet | 03/17/2025 | GreatVoyage-v4.8.0.2 （Kant） | Forked (Enabled No.83, No.88, No.89 Network Parameters)| 117 | | [Mainnet](https://tron.network/) |https://github.com/tronprotocol/java-tron | 04/29/2025| GreatVoyage-v4.7.7(Epicurus) | - | 118 | | [Shasta](https://www.trongrid.io/shasta) | https://github.com/tronprotocol/java-tron | 04/29/2025 | GreatVoyage-v4.7.7(Epicurus) | - | 119 | 120 | Nile Upgrade Instruction: https://nileex.io/run/getRunPage 121 | 122 | Mainnet/Shasta Upgrade Instruction： https://tronprotocol.github.io/documentation-en/releases/upgrade-instruction 123 | 124 | 125 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # TRON Project Management Repository 2 | 3 | This repository is used for project management for various discussions and initiatives affecting the TRON protocol. 4 | This repository is for: 5 | 6 | - [TRON Core Devs Meetings](https://github.com/tronprotocol/pm/tree/master/TRON%20Core%20Devs%20Meetings) 7 | - [SR Meetings](https://github.com/tronprotocol/pm/tree/master/SR%20Meetings) 8 | - [Mainnet Upgrade](https://github.com/tronprotocol/pm/tree/master/Mainnet%20Upgrade%20Archive) Specifications 9 | 10 | Agendas for these meetings can be found on the [Issues](https://github.com/tronprotocol/pm/issues) tab. 11 | 12 | ## TRON Core Devs Meetings and SR Meetings Overview 13 | 14 | ### Purpose 15 | The TRON core devs meeting is a technical gathering for developers shaping the TRON protocol. They share project updates, discuss [TIPs](https://github.com/tronprotocol/tips) for protocol improvements, and collaborate. Conversely, the SR meeting centers on community governance and ecosystem health. Elected SRs deliberate on boosting community engagement, crafting growth policies, and addressing issues threatening community well-being. This distinction ensures both technical progress and community-led development of the TRON network receive strategic attention. 16 | 17 | ### Agenda Items 18 | Agendas are posted to https://github.com/tronprotocol/pm/issues. Anyone is welcome to add an item to the agenda as long as it follows these guidelines: 19 | 20 | - The topic is technical in nature 21 | - The topic involves the TRON protocol 22 | 23 | Please note: 24 | 25 | - Dapps are generally not allowed as topics 26 | - The topic should not be philosophical 27 | 28 | The core devs meetings are not meant to decide philosophical contentious issues that should be decided by the community. 29 | 30 | ### Who Can Attend 31 | These meetings are held by TRON core devs. The following groups are invited to attend the meetings: 32 | 33 | - TRON core developers 34 | - client developers 35 | - core TRON researchers 36 | 37 | Sometimes, a non-core java-tron developer with particular expertise on a topic is invited on to discuss a specific agenda item. If you feel you would contribute to the meetings please contact coredevs@tron.network. 38 | 39 | ### Previous Meetings 40 | 41 |
42 | TRON Core Devs Meetings 43 | 44 | № | Date | Adgenda |Notes | Recording | 45 | --- | -------------------------------- |:--------------:|:--------------:|:--------------------:| 46 | 1 | Wed, 15 Jan, 2020 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/1) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2001.md) | [video](https://www.youtube.com/watch?v=-kHiycFhnf8) | 47 | 2 | Mon, 17 Feb, 2020 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/3) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2002.md) | [video](https://www.youtube.com/watch?v=ms3D8zL9_Dk) | 48 | 3 | Mon, 02 Mar, 2020 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/4) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2003.md) | [video](https://www.youtube.com/watch?v=aegtFI4D_c0) | 49 | 4 | Mon, 16 Mar, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/5) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2004.md) | [video](https://www.youtube.com/watch?v=hf_kpDRteB4) | 50 | 5 | Mon, 13 Apr, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/6) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2005.md) | [video](https://www.youtube.com/watch?v=GAi-I2MlGgM&t=11s) 51 | 6 | Thur, 30 Apr, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/7) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2006.md) | [video](https://www.youtube.com/watch?v=xXY7kf4tV-Q&feature=youtu.be) 52 | 7 | Tues, 16 Jun, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/8) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2007.md) | [video](https://www.youtube.com/watch?v=fY6sG285ee4) 53 | 8 | Tues, 11 Aug, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/11) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2008.md) | [video](https://youtu.be/EX63qtcvNAc) 54 | 9 | Thu, 24 Sep, 2020 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/14) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2009.md) | [video](https://youtu.be/jq_tvSXnXss) 55 | 10 | Wed, 20 Jan. 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/15) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2002.md) | NA 56 | 11 | Thu, 20 May 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/17) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2003.md) | NA 57 | 12 | Thu, 11 Aug. 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/19) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2004.md) | NA 58 | 13 | Wed, 26 Oct. 2022 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/30) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2005.md) | NA 59 | 14 | Wed, 08 Feb. 2023 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/37) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2006.md) | NA 60 | 15 | Wed, 07 Jun. 2023 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/50) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2010.md) | NA 61 | 16 | Wed, 19 Jul. 2023 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/60) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Wallet%20Devs%20Meeting%2001.md) | NA 62 | 17 | Fri, 02 Feb. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/72) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2011.md) | NA 63 | 18 | Fri, 08 Mar. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/75) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2012.md) | NA 64 | 19 | Thu, 21 Mar. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/78) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2013.md) | NA 65 | 20 | Thu, 11 Apr. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/82) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2014.md) | NA 66 | 21 | Thu, 25 Apr. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/86) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2015.md) | NA 67 | 22 | Thu, 16 May 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/91) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2016.md) | NA 68 | 23 | Thu, 30 May 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/93) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2017.md) | NA 69 | 24 | Thu, 13 Jun. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/94) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2018.md) | NA 70 | 25 | Thu, 04 Jul. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/95) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2019.md) | NA 71 | 26 | Thu, 18 Jul. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/96) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2020.md) | NA 72 | 27 | Thu, 08 Aug. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/97) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2021.md) | NA 73 | 28 | Thu, 22 Aug. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/99) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2022.md) | NA 74 | 29 | Thu, 05 Sep. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/100) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2023.md) | NA 75 | 30 | Thu, 26 Sep. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/101) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2024.md) | NA 76 | 31 | Thu, 24 Oct. 2024 07:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/102) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2025.md) | NA 77 | 32 | Thu, 07 Nov. 2024 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/104) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2026.md) | NA 78 | 33 | Thu, 21 Nov. 2024 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/105) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2027.md) | NA 79 | 34 | Thu, 05 Dec. 2024 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/106) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2028.md) | NA 80 | 35 | Thu, 19 Dec. 2024 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/107) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2029.md) | NA 81 | 36 | Thu, 09 Jan. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/108) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2030.md) | NA 82 | 37 | Wed, 26 Feb. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/112) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2031.md) | NA 83 | 38 | Wed, 12 Mar. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/114) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2032.md) | NA 84 | 39 | Wed, 02 Apr. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/116) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2033.md) | NA 85 | 40 | Wed, 16 Apr. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/120) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2034.md) | NA 86 | 41 | Fri, 18 Apr. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/121) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2035.md) | NA 87 | 42 | Thu, 24 Apr. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/122) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2036.md) | NA 88 | 43 | Thu, 08 May 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/129) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Wallet%20Devs%20Meeting%2002.md) | NA 89 | 44 | Tue, 13 May 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/127) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2037.md) | NA 90 | 45 | Wed, 28 May 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/136) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2038.md) | NA 91 | 46 | Fri, 06 Jun. 2025 06:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/140) | [notes](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2039.md) | NA 92 | 93 |
94 | 95 |
96 | SR Meetings 97 | 98 | № | Date | Adgenda |Notes | Recording | 99 | --- | -------------------------------- |:--------------:|:--------------:|:--------------------:| 100 | 2 | Wed, 20 Jan, 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/15) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2002.md) | NA | 101 | 3 | Thur, 20 May, 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/17) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2003.md) | NA | 102 | 4 | Wed, 11 Aug, 2021 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/19) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2004.md) | NA | 103 | 5 | Wed, 26 Oct, 2022 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/30) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2005.md) | NA | 104 | 6 | Wed, 08 Feb, 2023 09:00 UTC | [agenda](https://github.com/tronprotocol/pm/issues/6) | [notes](https://github.com/tronprotocol/pm/blob/master/SR%20Meetings/SR%20Meeting%2006.md) | NA | 105 | 106 |
107 | -------------------------------------------------------------------------------- /SR Meetings/SR Meeting 02.md: -------------------------------------------------------------------------------- 1 | # TRON SR Meeting 02 Notes 2 | 3 | ### Meeting Date/Time: Wednesday, 20th Jan. 2021, 9:00 AM UTC 4 | 5 | ### Meeting Duration: 1 hour 6 | 7 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/15) 8 | 9 | # Agenda 10 | 11 | - GreatVoyage-v4.1.2 Introduction. 12 | - [TIP-196](https://github.com/tronprotocol/tips/blob/master/tip-196.md) 13 | - [TIP-205](https://github.com/tronprotocol/tips/issues/205) 14 | - [TIP-207](https://github.com/tronprotocol/tips/issues/207) 15 | - Propose to increase the resource fee. 16 | 17 | ## Main features of GreatVoyage-v4.1.2 18 | 19 | - Sakary 20 | - Let’s first take a look at the new features of GreatVoyage-v4.1.2. Mainly 3 features. 21 | - First one, the new APIs for historical data, the user can query the account history balance at a specific block. you can find the detailed instruction from our official guide. 22 | - Second one, publish java-tron with Jitpack to be easily added as a dependency. 23 | - And TVM updates, including below 2 parts. 24 | - Support Solidity v0.6.0 25 | - Max_fee_limit can be changed now 26 | - These are the main update of GreatVoyage-v4.1.2. 27 | 28 | ## TIP-196 29 | 30 | * Sakary 31 | 32 | * Let’s first talk about the motivation of TIP-196. 33 | 34 | * One of the motivations is SR reward is low, especially compared with the prosperous network. and this TIP could improve the stability and efficiency of TRON network. at the same time, it will enhance SRs’ enthusiasm of packing transactions, after this TIP is implemented, SR will get $0.6 for each block(packed 70 trans) as an average, and it will be more if the transaction fee increases. 35 | * Here is the solution of TIP-196: Real-time reward method: transaction fee is sent to the SR who packages the transactions. 36 | 37 | * Do you have any questions? 38 | 39 | * Crypto Chain 40 | 41 | * I would say most SR will disagree with this TIP. First of all, SR reward is not low, most SRs have huge staking, and they can get huge rewards based on voting. and currently, the only way to destroy coin is the TRX burning for transaction fees, if we enable this TIP it will increase the inflation. 42 | 43 | * George 44 | 45 | * The community is very against this TIP. 46 | 47 | * Sakary 48 | 49 | * Justin Sun also shares his opinion on this TIP, seems no one agree with this TIP so far. 50 | 51 | 52 | 53 | 54 | ## TIP-205 55 | 56 | * Sakary 57 | 58 | * TIP 205 proposes an idea of the tokenization of the frozen TRX. 59 | * For now, the frozen TRX can only be used for voting, and the annualized return is about 7-8%. Apparently, this is low and will be a discouragement for staking. In a DPOS network, a low staking rate just equals instability and unreliability. 60 | * This TIP wants to encourage staking by increasing the profitability of TRX holders, in order to ensure the stability of the TRON network. 61 | * To let TRX holders more willing to stake, they must get more profit from it. The TIP mentions 2 rules: 62 | * The functions of frozen TRX are not limited to voting 63 | * Improve voting revenue. 64 | * With the rules, there comes 2 solutions 65 | * Design a TRC-10 token. At the time someone freezes his/her TRX, a fixed amount of the token will be gained. The token can be used to do operations more than voting, for example, mining. The token gained from freezing must be returned(burn) to unfreeze the corresponding TRX. 66 | * Deploy a set of TRC-20 smart contracts for each SR for users to vote. There will be a TRC-20 token. 67 | * The TIP prefers the first solution and gives options for setting the ratio to TRX. The ratio can be fixed or dynamic. do you have any questions? 68 | 69 | * Crypto Chain 70 | 71 | * I would not agree on this TIP, from my point of view, This TIP will increase the complexity for the user. our current voting mechanism is already very complex for the user to understand. after tokenized it will make it even more complex. 72 | 73 | * Justinas 74 | 75 | * From another point of view, if we go with the TRC-20 option, the smart contract way will bring more traffic to the network. And the current voting mechanism already works very well, no need to make it more complex. 76 | 77 | * George 78 | 79 | * One more question, what is the vision of “Mining” here? can you give an example? 80 | 81 | * Sakary 82 | 83 | * Currently this TIP is still under discussion, and the TIP does not mention this part. I would suggest you can directly start the discussion in the TIP page on GitHub, and everyone else can also see that. thanks. 84 | 85 | 86 | 87 | ## TIP-207 88 | 89 | * Sakary 90 | * TIP 207 proposes an idea of solving the low utilization rate of network frozen resources. 91 | * Executing transactions on TRON network requires bandwidth/energy. Currently, there are 2 ways to obtain resources. One is burning TRX, the price is 40 SUN. The other is freezing. 92 | * In the description of this TIP, about 76% of energy is obtained by burning. It also does a calculation, we know that the frozen income includes resource and voting rights. Taking 10000 TRX as an example, if I freeze this for bandwidth the income is approximately 0.056 USD daily, and 0.39USD for energy. 93 | * The TIP comes up with 2 solutions: 94 | * Freezing TRX gets only bandwidth, energy, or voting right. 95 | * Freezing to get vote right and share the network transaction fee. This means the burning TRX will be thrown into a pool and be distributed to all users who have frozen TRX. 96 | * The Resource obtained is calculated based on the total frozen amount, so it's clear that the first solution will increase the resources that can be obtained by freezing. 97 | * The second solution makes no difference to those who burn TRX for resources, but it brings extra profitability to the voters. The calculation shows that there can be approximately 0.02 USD from the pool. 98 | * Crypto Chain: 99 | * I am gonna agree with the first option, it is a very good proposal. If we go with the first option, it might increase the TRX freezing amount. for exchanges they may need both vote and energy, they may freeze more TRX to get extra energy if they do not want to reduce the voting. 100 | * From another point of view, for energy itself. it might be cheaper because most users may choose to freeze for voting, so the total freezing TRX for energy is less, same freezing TRX will get more energy. 101 | 102 | 103 | 104 | ## Increase the Resource cost 105 | 106 | * Sakary 107 | * ![burned TRX](https://github.com/Benson0224/imageonly/blob/main/burned%20TRX.png) 108 | * ![volume](https://github.com/Benson0224/imageonly/blob/main/volume.png) 109 | * ![Circulation](https://github.com/Benson0224/imageonly/blob/main/Circulation.png) 110 | * Let’s first take a look at these data, the transaction fees have been increased from 10 sun to 40 sun on 25th Nov. 2020. The TRX burning was rising, the transaction volume looks quite stable, the circulation was also rising. So some SR suggest to double the transaction fees, could you please share your opinions? 111 | * CryptoGuyinZA 112 | * It is good to increase the fee, but not the moment now. There are already transaction movement now, we need more uses to come to the TRON network, if we increase the fee, we will lose users. 113 | * Justinas 114 | * It is very good to have these graphics to see what is changed, it is really good resources, it would be great if it can be published and be seen by everyone on GitHub or other public places. regarding the increase the fee, we need more time to monitor, maybe 4-5 months, and then made a decison based on the data. 115 | * George 116 | * Please keep in mind that many other chains are already much cheaper than TRON, like Binance, increasing fee may driver users move to other chains. 117 | * Crypto Chain 118 | * Yes, compare to the Binance chain, Tron is not cheap, but compare to other mainstream chains, it is still very cheap. 119 | * We can’t just look at this topic from a cost perspective, it is not only about cost, for those chains with a lower fee, but their efficiency and stability are far behind TRON. They have many issues that impact the users. 120 | * CryptoGuyinZA 121 | * what is the goal of increasing the fees? 122 | * Sakary 123 | * From this data we can see there is no impact on transaction volume, more TRXs were burned, Circulation continues to rise. I would say fee increasing is helpful to the network. 124 | * CryptoGuyinZA 125 | * what is the timeline of this? The last time fee increasing is quite rush, we did not give DAPP developers enough time to adapt to the new fees. 126 | * Sakary 127 | * It is just a discussion now. we did not go that far. 128 | * CryptoChain 129 | * We should think from another point of view. 130 | * If the TIP-207 is online, with TIP-207, we probably have low fees because more users choose to freeze for voting to get rewards, this may be helpful for DAPP developers. 131 | * We should see how it works after TIP-207 is online, and then we can decide whether to increase the fees after we have detail data. 132 | * Do we have any schedule of TIP-207 implementation? 133 | * Sakary 134 | * Only for discussion now. 135 | * Justinas 136 | * Is this meeting recorded? can we see the meeting content in any public place? 137 | * Benson 138 | * No, this meeting is not recorded, however, we will summarize all the meeting content and publish the meeting content on GitHub so everyone can see it. 139 | 140 | 141 | 142 | 143 | 144 | ## Attendees 145 | 146 | - Benson 147 | - Andy Lu 148 | - Calvin 149 | - Crypto Chain 150 | - CryptoguyinZA 151 | - Genie Kim - NEOPLY 152 | - George (Tron Spark) 153 | - Joy 154 | - Justinas TeamTronics 155 | - LIU ZHI 156 | - Louis 157 | - Marco 158 | - Rainy 159 | - Rovak 160 | - Sakary 161 | - Samuel 162 | - Sean Liu 163 | - xiansheng liang 164 | 165 | -------------------------------------------------------------------------------- /SR Meetings/SR Meeting 03.md: -------------------------------------------------------------------------------- 1 | # TRON SR Meeting 03 Notes 2 | 3 | 4 | ### Meeting Date/Time: Thursday, 20th May. 2021, 9:00 AM UTC 5 | 6 | ### Meeting Duration: 1 hour 7 | 8 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/17) 9 | 10 | # Agenda 11 | 12 | - GreatVoyage-v4.2.0(Plato) Introduction. 13 | - [TIP-157](https://github.com/tronprotocol/tips/blob/master/tip-157.md) 14 | - [TIP-207](https://github.com/tronprotocol/tips/issues/207) 15 | - TRON Cross-chain progress 16 | 17 | ## Welcome 18 | 19 | - Sakary 20 | Good afternoon to all present here. 21 | 22 | I am Sakary, the host of the conference today. Before going right into the events, I'd like to thank each one of you for being with us today. Super representative is always one of the most important roles of TRON's ecosystem and I'm really honored that the chance to share our latest news here. 23 | 24 | ## Overview 25 | 26 | - Sakary 27 | 28 | At today's conference I'd like to focus on the following topics: 29 | 30 | Firstly, we've recently released the version of Great Voyage 4.2.0, also we call it Plato. The main content of this version update includes 2 TIPs, which are TIP-157 and TIP-207. 31 | 32 | The second topic is our latest progress of the TRON's cross-chain. Today we have Ray Wu here, he is on behalf of the cross-chain development and being ready to answer your questions. 33 | 34 | Last, I will invite you to join in the discussion about today's news. We always attach great importance to opinions from super representatives, I believe they will be helpful to the further work. 35 | 36 | Now let's move on to TIP-157. 37 | 38 | ## TIP-157 39 | 40 | - Sakary 41 | 42 | TIP-157 added 2 TVM instructions to support freezing related operations in TVM. The adding of the 2 instructions allows smart contracts to get resources from the staking mechanism. This means, from now on, smart contracts will be able to get and delegate resources to others. 43 | 44 | (Sample code displaying) 45 | 46 | Here is a sample contract. Smart contracts can delegate only resources but not TRON power to other accounts. TVM will prevent a contract from self destruction if it has freezing balance. 47 | 48 | Freezing assets for the resource is a unique mechanism for TRON, however, this is only available with ordinary accounts currently. Therefore, the development team want to give contract accounts the same ability, that is, by adding these TVM instructions. 49 | 50 | After this proposal goes into effect, it will be easy to build decentralisation energy banks with smart contracts, that can meet an outstanding need in the community -- energy renting and leasing. 51 | 52 | Also, contract owners are able to make full use of the assets staked in the contract, as freezing is a risk-free action. 53 | 54 | That's all about TIP-157, let's move on to the next part. 55 | 56 | ## TIP-207 57 | 58 | - Sakary 59 | 60 | TIP-207 has been proposed for some time. Compared with 157, in actual promotion, apparently, TIP-207 is more closely related to the interests of community developers and has sparked a lot of discussions. 61 | 62 | The resource had been got before this TIP became effective will not change, however resources will be recalculated if any adjustment is made. 63 | 64 | In the former resource mechanism, freezing whether for bandwidth or energy will definitely obtain TRON Power. Considering that many freezing behaviours are only for obtaining TRON Power, we believe this TIP can significantly imporve the resource utillization. 65 | 66 | 207 will mostly benefit developers those who freeze TRX only for resources. Also, this TIP may cause who originally obtains resources by burning TRX to switch to holding and freezing. 67 | 68 | This may effect the revenue of users who both develop and vote, however, this is not certain, because energy obtained by freezing is finally calculated based on the total amount of frozen for energy. Loss or gain needs to be calculated based on the final energy released. 69 | 70 | - CryptoChain 71 | 72 | At the beginnning of this proposal, I thought it could be very good for us. 73 | 74 | However, users have large amount of TRX, like exchanges, can still have a lot frozen for energy for TRC-20 transfers, and have a lot for voting. 75 | 76 | In the end, only users who have minimal TRX suffer from this. 77 | 78 | So, would it be possible to add some small gap on the maximum amount of energy to get, or at least some free energy, like we have some free bandwidth, so users can take at least 2 transactions of TRC-20. Something like we have with bandwidth. This may help users who make one or two transactions per day and they can still vote for SRs to get rewards from that. 79 | 80 | - CryptoChain 81 | 82 | I have another point. 83 | 84 | Right now there a lot of TRX frozen for energy. For big developers is OK. 85 | 86 | I was working with another project, they've all set on the test net. But the business model they have doesn't work on main net anymore, because the increasing of the price. 87 | 88 | Once we split it for energy and rewards, if they get reward from the staking system, they don't have enough to make energy. 89 | 90 | - Sakary 91 | 92 | You mean exchanges freeze TRX not only for voting, correct? 93 | 94 | - CryptoChain 95 | 96 | Exchanges have enough TRX put for voting, and enough for their TRC-20 transaction. So they have for both. Once they have both for energy and the voting system, they are ok. But developers can't, they need voting reward to compensate the energy that they don't have enough energy. 97 | 98 | So they really need the staking reward to compensate this part. 99 | 100 | - Sakary 101 | 102 | You mean some free energy like the bandwidth? 103 | 104 | - CryptoChain 105 | 106 | Yeah. Just a minimum, for just one or two transactions per day. 107 | 108 | - Justin Kairys 109 | 110 | I actually agree with CryptoChain. Now the smart contract related operations is getting more expensive. It would be good for developers at least to have some free energy without staking. Maybe for two or three transactions per day. 111 | 112 | - Benson 113 | 114 | Currently some projects freeze TRX for both energy and staking reward, later they use the reward to pay transaction fees, is that your point, CryptoChain? 115 | 116 | - CryptoChain 117 | 118 | Yes. 119 | 120 | - Benson 121 | 122 | If you don't do further freeze/unfreeze operation, the resources and TRON Power you have won't be changed. 123 | 124 | - CryptoChain 125 | 126 | There can be business adjustment that needs freezing strategy changes. There should be a gap, like if I freeze 2M TRX, I get 2M energy and 1M voting rights from that. 127 | 128 | - Benson 129 | 130 | I got you. Though the code implementation is done, there is enough time to discuss about this TIP, as this will keep disabled until SRs agree with this. 131 | 132 | - Justin Kairys 133 | 134 | Can you give an example, that who will only freeze for TRON Power. 135 | 136 | - Benson 137 | 138 | The answer is in the TIP. We've analysed the data and we did find some users are only interested in voting. The TIP starts from these statistics. 139 | 140 | ## Cross-chain 141 | 142 | ### Vision of the Future 143 | 144 | - Sakary 145 | 146 | Cross-chain is the process of data interoperability between two independent blockchains. It's mainly manifested in asset exchange and asset transfer. TRON started the cross-chain project long ago, because we believe that cross-chain is an inevitable stage in the development of blockchain. 147 | 148 | Due to limited resources, TRON restricts the number of cross-chain access to the TRON public chain. At the same time, we'll continue to introduce more detailed mortgage and incentive mechanisms, to reward honest parallel chains and punish malicious behaviours. 149 | 150 | A sound reward and punishment mechanism will attach high-quality projects to join the TRON ecosystem. 151 | 152 | ### Progress 153 | 154 | #### Slot Auction 155 | 156 | - Sakary 157 | 158 | Currently, the main functions accomplished are TRC-10/smart contract cross-chain, slot auction and parallel chain access. We start from slot auction. 159 | 160 | Like Polkadot, TRON will conduct parallel-chain slot auction soon. Refer to the description of in the related TIP, it is currently tentatively determinded that TRON will use the ordinary mark-up England auction method. 161 | 162 | The auction starts with a proposal that defines the round, number of slots, ending time and the slot expiration time. It costs 1,000 TRX to register for a candidate. 163 | 164 | Any user can vote for candidate chains by lock their TRX. These TRX will be locked till the end of the auction. For a winning candidate, the TRX used for voting will remain locked till the slot expiration time. 165 | 166 | The auction winner and TRON main chain will be recorded in each other's white list(to prevent duplicated bids). 167 | 168 | - CryptoGuyinZA 169 | 170 | I've got a question. Are we getting a slot on Polkadot or TRON? I'm just curious that should there be many TRON chains or what whould they be? 171 | 172 | Polkadot has substrate, and it allows you to connect heterogeneous chains to Polkadot. 173 | 174 | - Sakary 175 | 176 | Currently the parallel chains should be another java-tron. You can make changes, but basically they are java-tron. The cross-chain is still on development. 177 | 178 | - CryptoChain 179 | 180 | Right now we have a side chain, SUN network, it's basically the same thing. 181 | 182 | Why don't we just have a slot on Polkadot, as there have already been many chains on it. 183 | 184 | - Benson 185 | 186 | Currently, the auction only works with TRON chains. It works with huge DAPPs for now. 187 | 188 | - CryptoGuyinZA 189 | 190 | Polkadot allows different chains, and each chain brings different functionalities. There no value being added if there are many java-trons getting connected to each other. 191 | 192 | What is the value being added to that? 193 | 194 | - CryptoChain 195 | 196 | If there are just many TRON chains, we're going a different model with Polkadot. It's model of expension. 197 | 198 | - CryptoGuyinZA 199 | 200 | I'm not going to participate this auction if the model is like this. It's no reason join in this auction and win a slot. 201 | 202 | The main take away, you guys should think more about it, not technically, maybe the business model. 203 | 204 | - Ray 205 | 206 | We can do customisations to the actuators to make parallel chains different from TRON's mainnet. 207 | 208 | For historical reason, we must be compitable with smart contracts. 209 | 210 | So basically we have two solutions for the cross-chain: actuator modification and smart contract cross-chain. 211 | 212 | As for parallel chains of Polkadot, their business logic is hard coded in Substrate, however we provide the flexibility in smart contracts. 213 | 214 | - Sakary 215 | 216 | Our development is still ongoing. Certainly we will support heterogeneous cross-chain in the future. 217 | 218 | - CryptoGuyinZA 219 | 220 | The degree of customization determines its value. 221 | 222 | - Sakary 223 | 224 | We'll give details in TIPs. 225 | 226 | - Justin Kairys 227 | 228 | I think the main purpose of the cross-chain is to connect different blockchain networks. 229 | 230 | - CryptoGuyinZA 231 | 232 | In Polkadot, different parallel chains will do specific functionalities, like smart contracts, DEFIs and stable coins and different chains have their own chains. That's things about value. Without value, people have no motivations to participate the slot auction. 233 | 234 | You should think about the use cases. 235 | 236 | #### TRC-10 Transfer 237 | 238 | - Sakary 239 | 240 | TRC-10 is the first asset can be transfered between parallel chains. 241 | 242 | The original TRC-10 asset, I call this 'origin token', will have been mapped to a token I call that 'mirror token'. This mapping will always remain the same. The circulation of the origin token and the mirror token will be the same as the token circulation before any cross-chain transactions. 243 | 244 | - CryptoChain 245 | 246 | The main thing is for what chain can we transfer TRC-10 tokens to? We need to think about the business model. What is the value can we add to the cross-chain ecosystem if there are just TRON chains? 247 | 248 | #### Smart Contract Cross-chain 249 | 250 | - Sakary 251 | 252 | The smart contract cross-chain requires some preaparations: 253 | 254 | - Firstly, the contract author(owner) deploy 2 contracts on a pair of parallel chains 255 | 256 | - A full transaction will be taken into 2 parts. In the implementation, there should be 2 'triggersmartcontract' transactions, which are respectively responsible for the processing of the sender and the receiver. 257 | 258 | For now, the contract caller must have enough knowledge of Solidity, to ensure whether the function logic meets the expectations. 259 | 260 | Please refer to TIP-246. 261 | 262 | ## Roadmap 263 | 264 | - Sakary 265 | 266 | There remain several things to do this year: the cross-chain team will launch a pioneer test net, which is called Apollo. Apollo will go through the complete parallel chain linking process, including: slot auction before the cross-chain function is available on the mainnet. 267 | 268 | Through the operation of the test net, the team will make further optimisation in response to the problem found during the test. 269 | 270 | ## Remark 271 | 272 | - Sakary 273 | 274 | Now that we have come to the end of this conference. We've just released version 4.2.0, and simultaneously, I'm pleased to inform you that a testnet of TRON's cross-chain solution is ongoing. Cross-chain will be an excellent promotion of the entire ecosystem of TRON. 275 | 276 | Finally, I would like to close my remarks and express my appreciation to all the participants for taking time out of your busy duties to attend this conference. Thank you and see you here next time. 277 | 278 | 279 | 280 | # Attendees 281 | 282 | - Benson 283 | - Sakary 284 | - BitTorrent 285 | - Crypto Chain 286 | - CryptoGuyinZA 287 | - David Yang 288 | - Genie Kim - NEOPLY 289 | - Ivan 290 | - Jason Neely 291 | - justyy 292 | - Niioxce 293 | - Ray 294 | - Sean 295 | - Sean Liu 296 | - Tron Spark - George 297 | - Justin Kairys 298 | -------------------------------------------------------------------------------- /SR Meetings/SR Meeting 04.md: -------------------------------------------------------------------------------- 1 | # TRON SR Meeting 04 Notes 2 | 3 | ## Meeting Date/Time: Wednesday, 11 Aug 2021, 9:00 UTC 4 | 5 | ## Duration: 1 hour 6 | 7 | ## [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/19) 8 | 9 | ## Agenda 10 | 11 | - [TIP292](https://github.com/tronprotocol/tips/issues/292) 12 | - [TIP293](https://github.com/tronprotocol/tips/issues/293) 13 | - [TIP295](https://github.com/tronprotocol/tips/issues/295) 14 | - [TIP271](https://github.com/tronprotocol/tips/issues/271) 15 | - [TIP306](https://github.com/tronprotocol/tips/issues/306) 16 | - [TIP276](https://github.com/tronprotocol/tips/issues/276) 17 | - [TIP285](https://github.com/tronprotocol/tips/issues/285) 18 | - [TIP298](https://github.com/tronprotocol/tips/issues/298) 19 | - Other Changes 20 | 21 | ## Detailed Record 22 | 23 | ### Welcome 24 | 25 | - Sakary 26 | 27 | Good afternoon to all present here. 28 | 29 | I am Sakary, the host and the of the conference today. Before going right into the events, I'd like to thank each one of you for being with us today. I'm really honored that the chance to share our latest news here. 30 | 31 | ### Overview 32 | 33 | - Sakary 34 | 35 | At today's conference I'd like to focus on the following topics: 36 | 37 | We've recently released the version of Great Voyage 4.3.0, also we call it Bacon. A great many improves were included in this upgrade. 38 | 39 | In the rest of today's conference, we will talk about the upgrade from several perspectives. 40 | 41 | Firstly let's move on to the improves of the protocol core. 42 | 43 | ### Protocol Core 44 | 45 | - Sakary 46 | 47 | Everyone may have noticed that each time you made a transaction, small amounts of TRX or TRC-10 tokens would be sent to you. Scammers send low-value transfers( or we can call them spams) in this way. We've considered that the cost of sending spam is definitely low, and it's necessary to make changes when these kind of transactions take up too much network resources. 48 | 49 | For example, for the scam token [1004324](https://tronscan.org/#/token/1004324/), it has controlled 37, 871 addresses to airdrop fraudulent tokens to users continually. Each address can send about 17 free transaction in a day (Currently, the free net limit of an account is 5000, for the average 280 bandwidth consumption of a transaction, it allows the account to send about 17 (5000/280) free transactions in a day), then the scam token can send about 643, 807 fraudulent transactions everyday without any cost, which will lead to a great waste of precious resources in TRON network. 50 | 51 | Spams are sent mostly through non-contract transactions, as bandwidth is usually considered as a cheaper resource. It really is. Now these two parameters are adjustable, and the committee can make timely adjustments according to prevent. 52 | 53 | - Sakary 54 | 55 | The other change to the protocol core is about the data structure of Account. Shortly, we considered users' TRC-10 related data as uncommon, and moved them to a new store. 56 | 57 | This structure improves the IO efficiency. After this change, normal and smart contract trasactions will no longer call TRC-10 data. 58 | 59 | ### TVM 60 | 61 | #### Vote Instructions and Precompile Contracts 62 | 63 | - Sakary 64 | 65 | After TIP-157, smart contracts can freeze their TRX balance to get resource, including TRON power. However, smart contracts are not yet able to vote and get that part of reward. 66 | 67 | With the new feature, smart contracts will have full power over their balance, and get potentially more advantages from it. 68 | 69 | #### Type `Error` 70 | 71 | - Sakary 72 | 73 | The other new feature of TVM is the type of `Error`. 74 | 75 | To adapt Solidity 0.8.4, a new type `Error` is added to TRON's smart contract ABI. 76 | 77 | ### API 78 | 79 | - Sakary 80 | 81 | I believe this is the function that users have the most interest in. 82 | 83 | This field gives users a path to evaluate the energy cost before the transaction going on chain. When invoking the function of `TriggerconstantContract`, a sandbox environment based on the most recently synchronized block at the current node is created to supply TVM with this method call. 84 | 85 | - CryptoChain 86 | 87 | Can user trigger it many times to overload the node? Or will you have any limitation methods? 88 | 89 | - Benson 90 | 91 | You are right. We don't have this kind of functions. If there is a user keeps on triggering the API, the node can be overloaded. 92 | 93 | ### Changes 94 | 95 | #### SpongyCastle -> BouncyCastle 96 | 97 | - Sakary 98 | 99 | The latest release of SpongyCastle is on 2017. For safety considerations, since version 4.3, the cryptography library has been changed to BouncyCastle. 100 | 101 | #### Block Verification Acceleration 102 | 103 | - Sakary 104 | 105 | From version 4.3, during the block verification process, except from `AccountUpdateContract`, transactions will no longer be verified for the second time. (`AccountUpdateContract` changes account permissions). 106 | 107 | #### Node Startup Acceleration 108 | 109 | - Sakary 110 | 111 | Java-tron used to read transaction and block caches to initialize the transaction cache. This time, some unnecessary parsing process has been removed from the cache initialization. 112 | 113 | Else, a plugin call `archive-manifest` is added to streamline the file of `manifest` and accelerate the start up of levelDB. 114 | 115 | These changes have about ten times' speed up to our test machines. Also, there are some positive comments from the community on github. 116 | 117 | ### Energy Fee 118 | 119 | - Sakary 120 | 121 | The community proposed to increase the energy to 420 sun. 122 | 123 | The unit price of energy and bandwidth has been increased twice, firstly increased from 10 sun to 40 sun on 25th Nov. 2020, secondly increased from 40 sun to 140 sun on 11th Feb. 2021, and in the months that followed, the daily Net new TRX has been greatly reduced due to more TRX burned. For details, see [this](https://tronscan.org/#/data/charts/supply). 124 | 125 | On the other hand, due to the increased fees, users will get bandwidth or energy by staking TRX to reduce the consumption of TRX. With the increase in fees, the TRX staking ratio also shows a growing trend. From 22% in early November 2020 to 32% in mid-July 2021, the network-wide stacking rate has increased by about 10%. For detail, see [this](https://tronscan.org/#/data/charts/OverallFreezingRate). 126 | 127 | The following two graphs show that the number of energy obtained by burning TRX starts to decrease, while the number of energy obtained by staking TRX is increasing shortly after the fee increase, such as after April 2021. Check detail at [here](https://tronscan.org/#/data/stats/EnergyConsume). 128 | 129 | In addition, there was no significant change in the daily transaction volume after the two proposals to increase the unit price of energy and bandwidth on November 25, 2020, and February 11, 2021. Even after January 20, 2021, there was a significant increase in daily transaction volume, from a previous average of approximately 2 million transactions per day to a daily average of approximately 3.5 million transactions per day. In late July, the average daily number of transactions grew to 5 million transactions. The above data suggest that the increase in fees did not lead to a decrease in transaction volume. Check detail at [here](https://tronscan.org/#/data/stats/txOverviewStatsType). 130 | 131 | - CryptoChain 132 | 133 | Right now most developers want lower fees. Exactly the low-value transaction will be harmful to the network and nodes. However we've just increased some fees recently, community will not like this, especially the gamers and developers.You are wanting to increase the fee to reduce low-value transactions, but I don't think it's a good idea to do this right now. We can do it in other ways. My opinion is not doing this at this time. 134 | 135 | - TronSpark 136 | 137 | This will impact the applications that rely on low-value transactions, especially gaming, as they rely on small value transactions. We're no longer the cheapest choice. We just increased the fee recently. I agree with CryptoChain that not to increase the fee, and I think the community will be against it. 138 | 139 | - Team Tronic 140 | 141 | TRX's price used to be 30 cents, and with the rising price, developers had already suffered from the doubled price. 142 | 143 | ### Free Net Limit Reducing 144 | 145 | - Sakary 146 | 147 | We've received an another suggestion, to reduce some of the free bandwidth. It may start after the former proposal on GitHub. 148 | 149 | - Benson 150 | 151 | How much free bandwidth do you think should be appropriate? 152 | 153 | - CryptoChain 154 | 155 | 3 or 4 free transactions may be possible numbers. We can get a number from the statistics. For example, statistics from the past two months, we can use this to decide how many free transactions do normal users exactly need per day. 156 | 157 | - Sakary 158 | 159 | I need to say these two proposals are still in the stage of discussion. 160 | 161 | - Klever 162 | 163 | I don't know if these will be accepted by the community. TRON is not the cheapest chain anymore, some applications may be moved to other chains. Maybe we should have another way to remove spam or scammers. It's important to address how many accounts from the 1.4M are actually real. 164 | 165 | ### Other 166 | 167 | - Team Tronic 168 | 169 | SUN is the smallest unit of TRX but also a kind of TRC-20 token. It's not friendly to new developers. Do you have any plan to rename any from these? 170 | 171 | - Benson 172 | 173 | We've notice this, but it's really hard to change the name. I'll talk to the team later. 174 | 175 | ## Attendance 176 | 177 | - Ant 178 | - Benson 179 | - BinanceStaking 180 | - Crypto Chain 181 | - CryptoGuyinZA 182 | - David Yang 183 | - justyy 184 | - Kayle Liu 185 | - Klever 186 | - NEOPLY 187 | - Sakary 188 | - Team Tronics 189 | - Tron Spark 190 | - Wayne Zhang 191 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 20.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 20 2 | ### Meeting Date/Time: July 18, 2024, 7:00-8:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/96) 5 | ### Agenda 6 | * [Improve Unit Tests Code Coverage to 70%](https://github.com/tronprotocol/java-tron/issues/5434) 7 | * [More detailed results of the execution of the CANCELALLUNFREEZEV2(0xdc) opcode](https://github.com/tronprotocol/java-tron/issues/5530) 8 | 9 | ### Details 10 | * Jake 11 | 12 | OK, let’s roll. Today we have the Core Devs Community Call 20th, and there are two issues need to be discussed. The first one is shared by Daniel. 13 | 14 | * Daniel 15 | 16 | Sure, alright. Since last October, we have experienced several updates on the unit test coverage rate, and before that, Kayle was in charge of it. Here are a few records of the previous updates on the unit test coverage rate. Regarding the details of the unit test coverage rate for each module, currently, I see that the latest unit test coverage rate is 66.83%, which is a few percentage points short of 70%. According to the unit test coverage rate of each module, the coverage rate of the Framework part is relatively low, with Actuator at 75%, Chainbase at 77%, Common at 61%, and Consensus at 63.75%. My idea is to increase the coverage rate of the modules that are below 70%, and the team should try to increase the coverage rate as close to 70% as possible, as the coverage rate of each module is too low. 17 | 18 | Next, we can specifically check which modules have a lower coverage rate, which is under the framework directory. There are several sub-modules under Framework, including Common, Core, Keystore, and Program, and the coverage rates of these are all very low and seriously insufficient. Regarding Program, my idea is to allocate tasks among several active teams in the community to try to increase the unit test coverage rate as much as possible, whether it is to improve other modules or mainly to improve the framework module, we should try to increase the overall coverage rate to reach a goal of 70%. 19 | 20 | Ray, are you there? 21 | 22 | * Ray 23 | 24 | Yeah. 25 | 26 | * David 27 | 28 | We cannot solely rely on the coverage rate here; we also need to consider the number of lines of code in each module. Otherwise, it will be difficult to allocate the work. The specific workload is different. 29 | 30 | * Daniel 31 | 32 | I understand that the number of code lines in each module varies greatly. For example, if the coverage rate of the framework module can reach 71%, it is estimated that the overall coverage rate can also reach 70%. 33 | 34 | * Ray 35 | 36 | Should we reconfirm the content details and the workload in each module? If time is limited, it is best to focus our energy on the part with the highest priority and increase the proportion. This involves a more detailed task division. 37 | 38 | * David 39 | 40 | This workload may be very large. For example, there are more than 20,000 lines of code in Core. If it is allocated to developers in the community, the workload will vary greatly. 41 | 42 | * Daniel 43 | 44 | I just proposed to increase the coverage rate. I did not directly allocate the work, and it still needs to be discussed. 45 | 46 | * Ray 47 | 48 | Although I have not looked at it carefully, I understand that some unit test coverage rates are very low, possibly because they are not very important. So, should we sort out a priority for each module? We can first divide the key and easy-to-do parts, and then see which module is suitable for which team to do or to be allocated evenly. 49 | 50 | * Jake 51 | 52 | Then, Daniel, could you supplement this in the issue later, write in more detail about the approximate workload of each module, and then see the comments and reactions from the community? 53 | 54 | * Daniel 55 | 56 | I think this is fine. 57 | 58 | * Jake 59 | 60 | Ray, what do you think? 61 | 62 | * Ray 63 | 64 | I think this form is also good. Because the workload is huge, it still needs to be discussed more widely in the community. It is a good idea to supplement it in the issue and let a wider range of developers discuss it. 65 | 66 | * Jake 67 | 68 | OK, let's temporarily settle this issue like this. Does anyone else have any other questions? 69 | 70 | * Jake 71 | 72 | OK, then let's move on to the next topic. Regarding the opcode, was it submitted by you, David? 73 | 74 | * David 75 | 76 | Yes, I will share the screen. 77 | 78 | The purpose of this function is as follows. In the system contract, we all know that there is an interface called `cancelallunfreezeV2`, which can cancel all the user's queued unfreeze or unstake operations. In the VM, there is also an instruction that implements a similar function to the system interface. The result of the internal transaction generated by this instruction, does not include the canceled quantity of each resource, only the total canceled amount. This is somewhat different from the current implementation of the system and interface. At the same time, for some statistical services, they may need to know which resources will be canceled in the instruction-level cancellation operation. This is the main purpose of this issue. 79 | 80 | There are two implementation methods. Plan A is to add a new internal transaction type for each resource. We see that there are three types of bandwidth, energy, and tron power. Plan B implementation method is to write the specific quantity of each resource in the note field of the internal transaction, which is equivalent to using the note field to record the cancellation quantity of the three resources separately. 81 | 82 | There have been some small discussions on this issue in the early stage, mainly focusing on the implementation method. I personally mentioned that some community members are more inclined to use Plan B. Plan A requires adding three transaction types, so for the back-end service and statistical service, they may need to add additional code to parse these three. 83 | 84 | Regarding the purpose and implementation plan of this function, does anyone have any opinions? 85 | 86 | * Daniel 87 | 88 | I see that a field has also been added in the system contract to record the canceled amount of these three types of resources separately. Then we can align with the system contract. 89 | 90 | * David 91 | 92 | Yes, that's right. The recording format uses a JSON format to record. 93 | 94 | * Ray 95 | 96 | Where is it recorded? 97 | 98 | * David 99 | 100 | In the extended field, `string extra`. 101 | 102 | There is another issue that needs to be discussed. Does this function require a hard fork? The current implementation plan adopts a switch mode, and this switch can be configured to control whether detailed information about the cancellation instruction is added to the extended field of the transaction. 103 | 104 | * Ray 105 | 106 | I want to confirm a question. Where is it placed in the internal transaction? 107 | 108 | * David 109 | 110 | Inside the `transaction info`. 111 | 112 | * Ray 113 | 114 | If the user is also monitoring events at the same time, will this field appear in the event report? 115 | 116 | * David 117 | 118 | If the switch is turned on, it will appear. If it is obtained, if he is monitoring the entire transaction's transaction info, this field will appear. 119 | 120 | * David 121 | 122 | This approach is similar to the previous one. When Stake 2.0 was launched, some internal transactions related to Stake 2.0 instructions were added. At that time, a switch design like this was used. This is because there is a hard fork, and the increase in internal transactions is not controlled by the hard fork. The switch is closed by default, and for users who need to track and record the cancel instruction and which type of resources unstaked are canceled, they can choose to turn on the switch. 123 | 124 | * Ray 125 | 126 | From the perspective of monitoring contract events, can it only add a log to the contract? 127 | 128 | * David 129 | 130 | Monitoring events needs to be in the implementation code, usually written in Solidity. The event logic has nothing to do with the instruction level, but it needs to be considered in the contract logic. 131 | 132 | * Ray 133 | 134 | It is necessary to add the log output of the instruction execution at the instruction level. 135 | 136 | * David 137 | 138 | Yes, specifically for this instruction. This instruction originally generated an internal transaction with only a total cancel amount and no specific type. Now, a switch is added to complete this. When the switch is turned on, the canceled resource type will be shown in the internal transaction. 139 | 140 | * Ray 141 | 142 | If it is Plan A, there may be compatibility issues. Is this a concern? 143 | 144 | * David 145 | 146 | Plan A is more like the processing method of new internal transactions when stake 2.0 was launched. All the instructions related to stake 2.0 added in the VM will add one or more corresponding internal transactions, and the switch mentioned earlier was used for control at that time. 147 | 148 | * Ray 149 | 150 | I am mainly not clear about the specific advantages and disadvantages of Plan A or B. Do both require a hard fork? 151 | 152 | * David 153 | 154 | The implementation of Plan B does not require a hard fork. It just uses a switch to control whether to output detailed information about the canceled resource types. 155 | 156 | * Ray 157 | 158 | Then Plan A requires? 159 | 160 | * David 161 | 162 | In fact, Plan A may not be required either. It is only necessary to clarify the storage location when storing the specific resource quantity. Three internal transactions are added, which is equivalent to storing the canceled amount of each resource. For the cancellation instruction, if Plan A is adopted, it may generate 1 to 4 internal transactions. For B, it is still the original situation, generating one internal transaction. 163 | 164 | * Ray 165 | 166 | Will B affect the business parsing? 167 | 168 | * David 169 | 170 | No, the extended field is not new. The voting instruction will use this field to store voting information. 171 | 172 | * Ray 173 | 174 | Will there be a situation where both the voting information and the details of the canceled resources need to be stored in one instruction? 175 | 176 | * David 177 | 178 | No, voting and canceling are two instructions and will not reuse the same internal transaction. For some active nodes, transaction info will participate in the calculation of the state, and I am not sure about this. 179 | 180 | * Ray 181 | 182 | Me neither, and it needs to be confirmed. 183 | 184 | * David 185 | 186 | If both nodes are active nodes, and one turns on this function while the other does not, it will definitely affect the state calculation. 187 | 188 | * Ray 189 | 190 | This part should not be involved in the calculation because theoretically, the `info` itself can also be switched, and the whole is controllable. 191 | 192 | * David 193 | 194 | What's everyone's opinion? Should it be made into a switch or a hard fork? Is a hard fork making a mountain out of a molehill? 195 | 196 | * Ray 197 | 198 | From the current situation, I think a switch is more reasonable. However, if it is from the perspective that the transaction info needs to have a state info root and needs to be extended to a consensus, then a hard fork is still better. 199 | 200 | * David 201 | 202 | In fact, there is already a switch for internal transactions. Even if we want to do the info root in the future, internal transactions will not participate in the calculation of the root. 203 | 204 | * Ray 205 | 206 | Oh, that's right. 207 | 208 | * David 209 | 210 | For the consensus, internal transactions need to be closed. When calculating the root, only the common part that is not controlled by the switch should be calculated. 211 | 212 | * Ray 213 | 214 | Yes, that's right. 215 | 216 | * David 217 | 218 | What do you think about the necessity of this function? 219 | 220 | * Ray 221 | 222 | I think it is still necessary from the perspective of the development of the ecosystem. 223 | 224 | * David 225 | 226 | There must be many upgrading requirements for Fullnode. That is to say, from the perspective of the community, is the priority of this function high? 227 | 228 | * Ray 229 | 230 | I think if such a function can be provided and compatibility can be maintained, it may be a reasonable idea. If this function is made into a switch, the development difficulty and cycle will be just fine, no problem. 231 | 232 | * David 233 | 234 | Does anyone else have any opinions? 235 | 236 | * Jake 237 | 238 | If not, then that's it for today. Thank you all for your time. Goodbye! 239 | 240 | 241 | 242 | 243 | 244 | ### Attendance 245 | * Ray 246 | * David 247 | * Andy 248 | * Daniel 249 | * Super 250 | * Murphy 251 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 21.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 21 2 | ### Meeting Date/Time: August 8, 2024, 7:00-8:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/97) 5 | ### Agenda 6 | * [Implement eth_getBlockReceipts method](https://github.com/tronprotocol/java-tron/issues/5910) 7 | 8 | ### Details 9 | * Jake 10 | 11 | OK, it seems everyone is here. Let's start today's topic. We only have one issue to talk about today, which is to implement the eth_getBlockReceipts method. Hi Brown, you submitted this one, right? 12 | 13 | * Brown 14 | 15 | OK, I'll share my screen. 16 | 17 | First, I'd like to introduce the background of this issue. A community developer submitted this issue some time ago. Ethereum has added some JSON-RPC interfaces in the past period, including the one we are going to discuss today, eth_getBlockReceipts. The submitter wanted to use this interface in TRON but found that TRON did not have this interface, so he posted this issue in the community for everyone to discuss whether it was necessary to add this interface. 18 | 19 | Based on the above situation, I have sorted it out. The implementation of TRON's compatibility with Ethereum's JSON-RPC interface was in June 2022, and it has been two years since then. According to my research, Ethereum has added 6 new general JSON-RPC interfaces, and 4 Geth-specific interfaces, and deleted one interface after that. 20 | 21 | Ray, you are more familiar with these interfaces. Can you introduce them? 22 | 23 | * Ray 24 | 25 | OK, let me talk about it. I know something about it. I'll focus on the key points. The other interfaces have nothing to do with our business, so I won't discuss them here. You can take a look at them yourself to familiarize yourself with the interface functions of Ethereum. 26 | 27 | EIP-1559 launched a new social model early on, and everyone should know that the fee model for the contract part of TRON currently also refers to the fee model of EIP-1559. There is also a dynamic fee mechanism, which can be simply understood as the gas price consisting of two parts, one is the base fee, and the other part is a dynamic fee. Users can adjust part of the fee independently. The base fee will be burned, and the part of the dynamic fee can be adjusted by the user, so that it will be rewarded to the miners. This is a background premise. 28 | 29 | After EIP-4844 was launched, a new type of blob transaction was added. The only difference between the blob transaction and the previous transaction is the addition of the blob field, and another set of fee models similar to EIP-1559 is implemented for the blob field. You can think that its social model is identical, but the two exist independently, so their names are base fee and blob base fee respectively. 30 | 31 | This is the new interface added for EIP-4844 transactions. Considering that TRON has not yet started to implement the 4844 function, theoretically, the interface does not need to be followed up urgently, at least the 4844 function is needed first. 32 | 33 | Then the third and fourth ones can be skipped as you can tell from their names. Then for the fifth one, just now I said that the fee calculation of 4844 is divided into two parts, one is the base fee, and the other part is the fee that the user can adjust. Then for the fifth one, I think it should be the maximum value of the part that the user can adjust the fee. 34 | 35 | I'm not sure about the sixth one, let Brown talk about it. And I skipped the second one just now. 36 | 37 | * Brown 38 | 39 | OK. Let's talk about the second one first. The function of the second interface is to obtain the historical price of the gas fee. 40 | 41 | * Andy 42 | 43 | Is the historical fee here for a given period or all historical prices? Is it queried by a given time or a given block? 44 | 45 | * Brown 46 | 47 | By default, it is to query all, and for a given block range, it is to query the price changes within the range. This is relatively easy to understand. Currently, compared to this, TRON can only query the current price, but not the historical price. 48 | 49 | The third interface, eth_getBlockReceipts, is to query the receipts of all transactions in a block. In Ethereum, it is called transaction receipt, and in TRON, it is called transaction info. We will take a look at the details of this interface later, and this is the main topic we are going to discuss today. The fourth one, TRON does not have Merkel proof, so we don't need to look at it. For the sixth one, eth_newPendingTransactionFilter, the interface creates a filter to filter specific pending transactions, and when a new transaction is filtered, a notification message will be received. The interface it calls behind is eth_getFilterChanges, but there is a condition that these two interfaces must both be local. 50 | 51 | I have classified these 6 interfaces into two categories, one is that Java-tron can consider implementing, and the other is that it is not necessary to implement. Among them, the second, third, and sixth interfaces can be considered for implementation by Java-tron. Just now I said that the sixth interface is a bit troublesome to implement. The interface it calls behind must be on the same fullnode and the same machine as it, which is difficult to implement, especially considering the situation of service providers like Trongrid. 52 | 53 | These are the six general interfaces. Let me briefly introduce the four interfaces used by the Go client. The first one, txpool_content, is to return all pending and queued transactions. The second one, txpool_inspect, is to return all pending and queued transactions in text form. The third interface is to query all transactions of a specific address in all pending and queued transactions. The fourth interface is the number of each of all pending and queued transactions. 54 | 55 | For the implementation of these four interfaces, my conclusion is that they can all be implemented. The difference is that TRON only has pending transactions, no queued transactions, and no such state. For the fourth interface, txpool_status, TRON has a similar HTTP interface, getPendingSizeServlet, which returns the size of the pending transaction. 56 | 57 | Finally, let's take a look at the deleted interface, eth_getWork. This interface is to return the hash of the current block, the seed hash, and the boundary conditions to be met. Currently, TRON only returns the current hash for this interface, and the latter two values are null. It may not be necessary to retain it under POS. 58 | 59 | Next, let's take a look at the main topic of this time, whether it is necessary to implement eth_getBlockReceipts; if so, whether the difficulty is great. 60 | 61 | If it is implemented, I'll briefly talk about the general technical route. First, you can obtain the info of all transactions in a block through getTransactionInfobyBlockNum in the wallet API. Alternatively, through the JSON-RPC method, it can be divided into the following two steps. The first step is to call eth_getBlockBy{Number, Hash} to retrieve all transactions of a certain block. The second step is to traverse all transactions obtained in the first step and call eth_getTransactionReceipt to obtain the info of each transaction, which is called the receipt in Ethereum. 62 | 63 | The interface formats obtained by the above two methods are very different, and complex format conversion is required. The later JSON-RPC method is very inefficient for obtaining a large number of blocks and transaction data. 64 | 65 | That's roughly the situation. Feel free to express your opinions to see if it is necessary to implement this interface. 66 | 67 | * Ray 68 | 69 | Is there any performance issue in implementing this interface? There will be a large amount of data returned in the info, and the data volume will be large, or the query frequency will be very high. Did the author of this issue mention in what scenarios this interface will be used? 70 | 71 | * Brown 72 | 73 | The author only mentioned that he found it incompatible when using it and hoped that TRON would improve its compatibility with Ethereum. 74 | 75 | * Andy 76 | 77 | There was a previous interface to query all log information within a block range, and the performance issue of that interface was very serious because the maximum query was 100. Currently, the number of transactions in a block in TRON can support up to four or five hundred, and usually, there will be three or four hundred. If the database is queried many times, then the serialization and deserialization situations need to be considered. From some results of the previous stress test, deserialization is still very time-consuming. 78 | 79 | * Brown 80 | 81 | Many interfaces in TRON now also have similar situations, and there are no performance issues. As for the deserialization situation, generally, the database will only be queried once, not 100 times. In some previous implementations, it was also executed one by one through getTransactionByInfo, and there was no problem. 82 | 83 | * Ray 84 | 85 | I think we still need to discuss the demand for this interface first. It is not certain whether the existing interfaces can support the business scenario mentioned by the issue author. In addition, I am not sure about the way Ethereum obtains the receipts. Do they store the blocks in the database, and the receipts are stored separately and can be directly obtained, or is it the same as TRON? If TRON stores them separately, our performance may be much worse than theirs. 86 | 87 | * Brown 88 | 89 | It was stored separately before, but now it is stored together. 90 | 91 | * Ray 92 | 93 | That means there is no need to traverse through when obtaining the info, right? 94 | 95 | * Brown 96 | 97 | No, only when converting, when doing the mapping, it needs to be traversed. 98 | 99 | * Ray 100 | 101 | The cost of modification will not have an impact on the underlying storage business logic. It only adds a read-only query interface. 102 | 103 | * Brown 104 | 105 | If the speed reduction is too fast, it may affect the read and write in other aspects. 106 | 107 | * Ray 108 | 109 | Whether to do this function still needs to be determined. At present, I don't have a good suggestion. If it is to be done, in the past, it may be necessary to test the performance and the limit of qps. 110 | 111 | * Brown 112 | 113 | Yes, let's see if the other interfaces should be done or not. 114 | 115 | * Jake 116 | 117 | Brown, it would be more convenient for everyone to see if you moved your screen to the table of the new interfaces you made. 118 | 119 | * Brown 120 | 121 | Here, everyone takes a look and thinks about it. 122 | 123 | * Ray 124 | 125 | I think you still need to go back to the issue and ask the author about the purpose of using the interface, in order to more accurately or in more detail understand the business scenario of the interface, and approximately how often it is used. 126 | 127 | * Brown 128 | 129 | This is one aspect. On the other hand, from a business perspective, TRON needs to directly improve its compatibility with Ethereum. Previously, when integrating with Metamask, there were problems with compatibility. This is also one of the motivations for doing this interface. 130 | 131 | * Andy 132 | 133 | I would like to add that it is still necessary to figure out which projects or scenarios the current JSON-RPC interface is used in. 134 | 135 | * Brown 136 | 137 | Yes, I will do my research on this later. Does anyone else have any other suggestions? 138 | 139 | * Jake 140 | 141 | If not, then that's it for today. Brown, you are responsible for following up on this issue, right? Including communicating with the author? 142 | 143 | * Brown 144 | 145 | Yes, I am responsible for it. 146 | 147 | * Jake 148 | 149 | OK, we will definitely discuss this issue again in the future. That's it for today. Thank you for your time, bye! 150 | 151 | 152 | 153 | ### Attendance 154 | * Ray 155 | * Brown 156 | * Andy 157 | * Boson 158 | * Allen 159 | * Lucas 160 | * Aaron 161 | * Super 162 | * Murphy 163 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 23.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 23 2 | ### Meeting Date/Time: September 5th, 2024, 7:00-8:00 UTC 3 | ### Meeting Duration: 70 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/100) 5 | ### Agenda 6 | * [Upgrade to JDK 17](https://github.com/tronprotocol/java-tron/issues/5976) 7 | 8 | ### Details 9 | * Jake 10 | 11 | Hello everyone! Today we are having Core Devs 23, and we will continue the topic from last time, which is about adapting to the ARM architecture. Shall we start now? Boson, are you here? 12 | 13 | * Boson 14 | 15 | Yes, let me get ready. 16 | 17 | Can you see my screen? 18 | 19 | * Jake 20 | 21 | Yes, we can. You can start now. 22 | 23 | * Boson 24 | 25 | We discussed this aspect last time, and now we can elaborate on the updates on several issues regarding the adaptation of the ARM architecture. 26 | 27 | The update mainly involves the issue of JDK versions, such as Oracle or Open JDK, and we need to consider Open JDK. Here I list examples of other vendors, such as Zulu and Amazon. In addition, Oracle JDK 17 will soon be charged, starting September 2024 for subsequent updates. If TRON wants to upgrade the JDK, when adapting to ARM, it may not consider using Oracle JDK but Open JDK instead. 28 | 29 | Next, let's talk about the data consistency issue. Whether it is supporting ARM or switching JDKs, the main problem is data consistency. At present, we haven't thought of any other methods except adding a state tree. If data consistency cannot be guaranteed, the subsequent work cannot proceed. 30 | 31 | * Ray 32 | 33 | I haven't thought it through, and I don't have any other ideas. Let's discuss it later. 34 | 35 | * Boson 36 | 37 | Then let's continue the discussion at the next meeting. At present, there is no good solution. Let's look at the matter of upgrading JDK 17. There is currently a problem regarding the commercial use of Java subscriptions. In a decentralized network like TRON, is the use of JDK in the client considered commercial use? 38 | 39 | * Andy 40 | 41 | It should be considered a commercial use, even if it is used for internal enterprise management, it is considered beneficial. 42 | 43 | * Boson 44 | 45 | This issue involves legal matters, and we still need to study it further. Let's move on to the next topic. Regarding the reason for upgrading to JDK 17 and skipping JDK 11, it is now certain that JDK 11 is charged. Because of the charge for JDK 11, everyone is dissatisfied. Starting from JDK 17, the charging method has changed. Older versions can be used for free on a trial basis, and subsequent updated versions will continue to be charged. 46 | 47 | * Andy 48 | 49 | If Open JDK is not used, then the current choice is to use version 21, which can be used until 2026. 50 | 51 | * Boson 52 | 53 | Another situation is to switch to Open JDK. Currently, due to unknown reasons, it is impossible to switch to Open JDK. Let's not discuss other options for now. At first, we chose version 17 because it was free. Now that version 17 is no longer free, it doesn't make much sense. Version 17 has better support for ARM, and the prerequisite for upgrading ARM is to upgrade to JDK 17. Version 17 has two problems. One is the garbage collector. ZGC has been in production since JDK 15. The other is the strict mode of JEP306. Starting from JDK 17, it can completely guarantee basic calculations, such as addition, subtraction, multiplication, and division, and they are consistent on any platform, without inconsistent behavior due to extended precision on certain platforms. 54 | 55 | There are also some changes in default behaviors, and I list three points here. The first is the change in null pointers. Previously, the message was null, so it was always a headache when troubleshooting null pointers. Now it has improved the null pointer, and it has a value since JDK 14. Then we currently found a way to judge the null pointer in the Java-Tron code or any other way. If the get message is equal to null, it is judged in the contract. If it is equal to null, it will catch and set a contract result. After JDK 17, for this type of null pointer, it is no longer equal to null, so compatibility is needed here. In addition, the garbage collector has removed CMS in JDK 17, and these are some problems. Also, when the module system was introduced in JDK 9, some classes in JDK 17 were inaccessible, and other problems such as log printing, JVM parameters, and garbage collection have also changed. Then regarding third-party dependencies, some dependencies may need to be upgraded, and here are some examples. There is also the same data consistency problem. If there is no state data, that is, without introducing state numbers, how to verify the consistency problem. Another issue is the problem of floating-point calculations, which may require a hard fork. 56 | 57 | There is another problem. Is it necessary to be compatible with both 8 and 17 at the same time? What are your thoughts? 58 | 59 | * Ray 60 | 61 | Is it under the ARM architecture? 62 | 63 | * Boson 64 | 65 | No, I mean in general. If we are compatible, we should be compatible with both, regardless of whether it is x86 or ARM. The current situation is that our code supports both 8 and 17, and it has always been in the development state of 8, and the syntax state has also been maintained in the syntax state of 8. When compiling, the source is 8, and the compiled class is also 8. 66 | 67 | * Andy 68 | 69 | TRON has many nodes, and it may take half a year or a year for all nodes to complete the upgrade. Compatibility should be necessary. 70 | 71 | * Boson 72 | 73 | The Java client of Ethereum does not consider this, and it upgrades directly. 74 | 75 | * Ray 76 | 77 | What does direct upgrade mean? 78 | 79 | * Andy 80 | 81 | It means directly specifying the version, and it is also upgraded from JDK 11, 17, and 21. 82 | 83 | * Ray 84 | 85 | Why does it consider upgrading Oracle JDK when it uses Open JDK? 86 | 87 | * Boson 88 | 89 | It supports Open JDK, but considering that many users deploy using Oracle, the client cannot limit which JDK is used, but it can limit the version to ensure that the versions used by everyone are free, so it was upgraded from 17 to 21. 90 | 91 | * Andy 92 | 93 | Ethereum has a significant characteristic. There is about one forced upgrade every year, so each upgrade must use the latest version. Due to the upgrade of Ethereum, it indirectly prompts the update of the client, and users are more motivated. TRON needs to consider this. If there is no forced upgrade, many nodes may keep using the old version of JDK. 94 | 95 | * Boson 96 | 97 | So if TRON insists on using JDK 17, it must be a hard fork version. 98 | 99 | * Ray 100 | 101 | Yes, I am still very worried about the occurrence of data inconsistency when upgrading the JDK, even if the probability is very low. If the old JDK version is forcibly replaced, will there be a greater risk? If such a thing happens, it may be disastrous. 102 | 103 | * Boson 104 | 105 | At the same time, being compatible with both JDK 8 and JDK 17, in my opinion, will also have disastrous consequences. In the most chaotic state, when both 8 and 17 exist at the same time, it will be more troublesome. If it is all 17, then it may not be so bad, and if it is all 8, it is also fine. As long as TRON's code can run on JDK 17, it is considered to support 17. 106 | 107 | * Ray 108 | 109 | I think it is highly unlikely that there will be a complete migration to JDK 17 in one upgrade. 110 | 111 | * Andy 112 | 113 | This cannot be done either. 114 | 115 | * Ray 116 | 117 | For safety reasons, this will not be done either, but when both 8 and 17 exist at the same time, it is actually very difficult to ensure that there are no problems. 118 | 119 | * Boson 120 | 121 | The result of the current discussion is to support both 8 and 17, that is, after a certain version, both 8 and 17, or all versions above 8 are supported. If multiple versions are supported for a long time, then the data consistency research must be completed. 122 | 123 | * Ray 124 | 125 | Then how to do the data verification problem? 126 | 127 | * Boson 128 | 129 | This is the most critical. I propose a small state number and make a state number for each latest session. 130 | 131 | * Ray 132 | 133 | I think the consistency research needs to be discussed separately, and this is the biggest risk point in the upgrade. 134 | 135 | * Boson 136 | 137 | Yes, for this consistency problem, everyone can think about what other good solutions there are. TRON must have this function. It supports consistency verification by itself, and this consistency verification cannot be a consensus, right? 138 | 139 | * Ray 140 | 141 | If it is not consensus when a problem is found after it is actually online, it is only a warning, and in fact, the data has already been messed up. I think there should be an upgrade and disaster recovery plan, at least a disaster recovery fallback plan to ensure that there is still a correct set of data when there is a problem online. 142 | 143 | * Boson 144 | 145 | Yes, a plan still needs to be designed. 146 | 147 | The first topic of this meeting is about commercial behavior. At present, we cannot clearly define which operations in the operation of TRON are considered commercial behaviors recognized by Oracle. 148 | 149 | The second is whether compatibility only supports version 17 or all versions above 8. At present, it seems that it should support all versions above 8, and there is no longer a limitation. 150 | 151 | * Ray 152 | 153 | This workload is very large. If it cannot be limited at the code level, can TRON's code limit it? 154 | 155 | * Boson 156 | 157 | So it is either use 8 or use 17? 158 | 159 | * Ray 160 | 161 | I think user feedback should also be considered. Should we support all versions above 8 and Open JDK versions? Grasp the user needs and workload. 162 | 163 | * Boson 164 | 165 | Then make a comment under the issue of upgrading JDK 17, and put these three topics of the definition of commercial behavior, supported JDK versions, and data consistency here for the community to discuss. Of course, we need to promote this situation in the community and attract a wider range of users to participate in the discussion. 166 | 167 | * Jake 168 | 169 | Is it to promote the link of the issue, briefly explain it, and attract the community developers to participate? 170 | 171 | * Boson 172 | 173 | Yes, promote both the adaptation of the ARM architecture and the upgrade of the JDK. 174 | 175 | * Jake 176 | 177 | Okay. Then after that, Boson will update the key points of this discussion. Does anyone else have any suggestions or opinions to discuss? 178 | 179 | * Jake 180 | 181 | If not, then that's it for today. Thank you all for attending the meeting. Goodbye! 182 | 183 | 184 | 185 | ### Attendance 186 | * Ray 187 | * Brown 188 | * Super 189 | * Andy 190 | * Boson 191 | * Daniel 192 | * Lucas 193 | * Aaron 194 | * Murphy 195 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 24.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 24 2 | ### Meeting Date/Time: September 26th, 2024, 7:00-8:00 UTC 3 | ### Meeting Duration: 45 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/101) 5 | ### Agenda 6 | * Introducing PowerMock to write unit tests for Java-tron 7 | 8 | ### Details 9 | * Jake 10 | 11 | Hello everyone. Today we are having Core Devs Community Call 24. Welcome everyone. For today's meeting, we have only one topic: "Introducing PowerMock to write unit tests for Java-tron" submitted by Super. 12 | 13 | Hi Super, can you hear me? Please share your screen and let's start now. 14 | 15 | * Super 16 | 17 | OK. Hi guys, I am going to explain why I would like to introduce PowerMock to write unit tests today. 18 | 19 | There are several advantages as follows. First, writing unit tests with Mock allows us to break the dependency between the test object and services. For example, some unit tests depend on the database startup or service startup corresponding to the API. If the mock method is used, the dependency on services or database startup can be removed, thereby reducing the memory occupied by services and saving a lot of resources. 20 | 21 | The second function is that it can replace service calls. For example, when we call a certain service, it can be written in the Mock way without specifically writing the service interface. In this way, the running speed of test cases will be faster. We can save a lot of service calls. For example, when calling service A, and A calls service B and service C, etc. If we make these services into Mock, it will save a lot of trouble. 22 | 23 | The third point is to improve test efficiency. For example, within a unit of time, you can run more tests and the speed can be faster. Java-tron has introduced the Mockito module. However, due to the insufficient power of Mockito, for example, it cannot mock static methods, private methods, and constructors. If Java-tron wants to increase the unit test coverage rate to 70% or more than 80%, only introducing Mockito is not enough. It cannot solve the need for Mock in many scenarios. 24 | 25 | After introducing PowerMock, we can use Mock to write unit tests. The coverage rate should be able to increase to 80% or even more. There is no problem that a certain function cannot be covered because it cannot be constructed. There are many reasons for not being able to construct. Its parameters are very complex and the dependent service is very complex. A large number of services need to be started to call this method. Parameter construction is very troublesome. If PowerMock is used, all problems can be easily solved. 26 | 27 | I will share my practice of using PowerMock to improve the unit test coverage rate of Java-tron during this period for your reference and communication. If you have any questions, we can discuss them later. If you want to use PowerMock, then you must reference its dependencies. Currently, it is the PowerMock 2.0 version. Then you also need to use the annotation RunWith(PowerMockRunner.class) to indicate that the test case is run using PowerMockRunner. This must be added, otherwise PowerMock cannot be used. Another annotation is PrepareForTest({Util.class}), which is used to add all classes that need to be tested. Usually, when testing a category, these two prerequisites need to be added. 28 | 29 | I have sorted out some relatively complex unit test cases written with PowerMock and share them with you. 30 | 31 | The first practice is that PowerMock can assign private member variables non-intrusively. For example, here, in the wallet class, there is a private variable, chainBaseManager, which has no `get` and `set` methods. It may be assigned through the constructor. In this case, testing will be more troublesome. If PowerMock is used, I can directly assign a value to it. Create a Mock object for chainBaseManager, and then directly call this Mock function. 32 | 33 | The second is to call private methods non-intrusively. For example, here, in the RuntimeImpl class, it has a private method setResultCode. If I want to write a unit test case for this private method, since it is private and cannot be called directly, reflection may be used, which will be more troublesome. If PowerMock is used, it can be solved with one line of code. According to the object I defined here, the private method can be called directly by using the function Whitebox.invokeMethod. If reflection mechanism is used, there will be much more code than here. PowerMock has many encapsulated methods like this, which is very convenient when writing. 34 | 35 | The third is to mock constructors. For example, here I have a class to be tested. The usage of its constructor is relatively complex, and it is very troublesome to write test case logic during testing. If PowerMock is used to write, here directly define this class, and then use the method whenNew to return a Mock object to test this class. 36 | 37 | Here are a few more examples. Similarly, mocking static methods and private methods is very simple and convenient when writing test cases. I recommend that you get familiar with the official wiki of PowerMock here. It has many powerful functions, and people who often write test cases will be very impressed. 38 | 39 | I encountered a problem during the practice process. There is an incompatibility issue between PowerMock and Jacoco. The reason is that a class is decorated in PrepareForTest. JaCoCo cannot perform coverage statistics in this class. Both of them implement the functions of statistical coverage and mocking static classes by modifying bytecode files when loading classes. JaCoCo inserts statistical code into the class when loading the class. However, when PowerMock uses the PrepareForTest annotation, it will re-read bytecode information from the class file when loading related classes, resulting in the modifications of JaCoCo being lost, so it cannot be statistically counted. The solution is to use the offline mode of JaCoCo. Look at me redefining the steps here. In the end, the path of the unit test coverage report is the same as before. Finally, just upload the coverage data. 40 | 41 | For example, after introducing PowerMock, when writing unit tests, no matter how complex the code method is, there can be corresponding relatively simple methods to implement. For example, the most complex is the manager test. If too many things are used and when running to a certain case, a lot of code needs to be written. If we construct a case, it is very complex. If the reporting method is used, it may be relatively simple. That's about it. Do you have any questions? 42 | 43 | * Andy 44 | 45 | What are the disadvantages or compromises of PowerMock for Java-tron tests? I see that you only shared the advantages. 46 | 47 | * Super 48 | 49 | The first is that the coverage statistics in not compatible with Jacoco. Although this has been solved, I don't think it is very sufficient. We still need to look at the specific situation of other modules later. 50 | 51 | The second is that it is based on Mockito. It can be understood as an extended version of Mockito. If Mockito has already been introduced, then PowerMock plays an icing on the cake role. 52 | 53 | * Andy 54 | 55 | How is its performance compared to before? Have you done a comparison? 56 | 57 | * Super 58 | 59 | Surely it is much better to use Mock. First, the dependency is removed. In terms of running speed, for example, the number of interfaces run per unit of time is obviously better than when running unit tests before. It is based on Mockito, but it has more powerful functions. However, if these functions are not used, there is not much effect. This depends on the specific situation. 60 | 61 | * Andy 62 | 63 | I understand. Does mocking these static methods and private methods still use Java's Reflection or something else at the bottom? 64 | 65 | * Super 66 | 67 | Yes, part of it uses Reflection, and part of it is bytecode manipulation. Basically, it can be understood that everything that Mockito cannot do but you want to use is added here. From the past unit test experience of Java-tron, for a case that was very troublesome to construct in the past and needed to write a unit test to run, PowerMock can solve it perfectly. There will be no case that cannot be solved. 68 | 69 | * Andy 70 | 71 | OK, I understand. 72 | 73 | * Super 74 | 75 | In addition, for newly written code in the future, a perfect 100% test coverage can also be achieved no matter how the code is written. 76 | 77 | * Super 78 | 79 | Any more questions? I see that some newly added unit tests have begun to be written with Mockito. I have looked at it. Many things that Mockito cannot solve can be solved by PowerMock. So I think it is very necessary to introduce it. 80 | 81 | * Andy 82 | 83 | Will there be a conflict if both are introduced to Java-tron? 84 | 85 | * Super 86 | 87 | No, they have corresponding versions. Its bottom layer also calls Mockito in part, and the other part is to strengthen it by modifying bytecode again. Lucas, do you have any opinions or questions? 88 | 89 | * Lucas 90 | 91 | No other questions for now. 92 | 93 | I suggest using Mock in the future and not depending on system startup. I basically use Mock for all my unit tests now. 94 | 95 | * Super 96 | 97 | Literally, there is no problem using Mockito. If we purely use Mockito, the code will be more complex. For example, when calling a private method, I see that when using Mock to call a private method, it is calling a private method using reflection. If PowerMock is used to call, the code is very simple. It has encapsulated all the content of calling private methods. There is no need to reprocess those things again. Just focus on construction and configuration. 98 | 99 | I have looked at the newly written unit tests and can do this. For some of the things that tested results fluctuated before, are the plans to keep them in the future? Do you have any ideas to redo them all over again? Do you have this idea? 100 | 101 | * Allen 102 | 103 | Is there a plan to refactor existing use cases with PowerMock later? 104 | 105 | * Super 106 | 107 | At present, I am working on improving coverage. However, for existing content, in-depth discussion may be needed. If the Mockito plus Power method is used for rewriting, it can indeed reduce the memory consumption of unit tests and execution speed, which is very helpful for the current situation. I think this issue can be discussed again. 108 | 109 | * Super 110 | 111 | I think we need to introduce the powerful content and functions of Power first, and then discuss in depth to see if refactoring is needed. If refactoring is done, the workload will be very large. 112 | 113 | * Allen 114 | 115 | So I understand that this still needs to be discussed and there is currently no plan. 116 | 117 | * Super 118 | 119 | That's right, currently only considering improving the unit test coverage rate. 120 | 121 | * Allen 122 | 123 | OK, I understand. 124 | 125 | * Super 126 | 127 | Any other questions? If not, I'll stop sharing here. 128 | 129 | * Jake 130 | 131 | Does anyone else have any questions? If not, today's meeting is over here. The next Call is tentatively scheduled for October 17. After that, we will adjust the development progress within the community in October according to the situation. Do you think it's okay? 132 | 133 | * Murphy 134 | 135 | Sure, 17th it is. If not in time, it could be postponed by one week to the 24th. Let's discuss this in the community. 136 | 137 | * Jake 138 | 139 | OK, that's it for today. Thank you all for attending. Goodbye! 140 | 141 | 142 | 143 | ### Attendance 144 | * Ray 145 | * Brown 146 | * Super 147 | * Andy 148 | * Allen 149 | * Lucas 150 | * Murphy 151 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 25.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 25 2 | ### Meeting Date/Time: October 24th, 2024, 7:00-8:00 UTC 3 | ### Meeting Duration: 45 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/101) 5 | ### Agenda 6 | * [ I cannot get results from api eth_getLogs sometimes](https://github.com/tronprotocol/java-tron/issues/6037) 7 | 8 | ### Details 9 | * Jake 10 | 11 | Hello everyone, let’s stop waiting for others and start now. I will check and let them know once they show up. We only have one topic to discuss today. An issue was raised on GitHub, where people complained about the eth_getLogs. It seems that, for some reason under certain circumstances, this API does not perform normally and return what was requested. 12 | 13 | Brown, you have dug into this one. Would you mind sharing your findings with us? 14 | 15 | * Brown 16 | 17 | Sure, one second. 18 | 19 | Everyone can see my screen, right? OK, this is a tricky one. Just now Jake briefly talked about it. I will explain the situation in detail. 20 | 21 | Someone in the community posted an issue regarding the return of the eth_getLogs interface. This interface requires an address and a specified block range to be passed in. Normally, it should return the logs and events related to the passed-in address. He gave an example in the issue, specifying an address and a range, but no log was returned. However, there are indeed logs for this address within this block range. He used the same interface with the JSON parameter and dropped the ‘address’ to verify it and successfully got the log. I tried to follow his steps to reproduce and found that the issue was real and it was a bug. 22 | 23 | I found other times in the block in his example and then used the relevant address of the relevant event as a parameter to call the eth_getLogs interface to query, and found that it could also be queried. But when using the address given in his issue to query, it could not be found. After that, I tried many other addresses and found that they could all query related events, which means the probability of this problem is extremely low. So I still focused on this specific address in his issue. I suspect that when this address is hashed in the code, the result may have a problem in the subsequent use of the code, that is to say, the problem may be caused by the specific result generated by the specific address, which leads to the occurrence of the exception. 24 | 25 | Based on this inference, I carefully look at the code of this interface and share it with you. The logic of writing and querying these logs to be queried is different, resulting in the writing conditions being more stringent than the querying conditions, which may be the cause of the problem. This interface has four main parameters, namely the address, two parameters of the block range, and the topic of the event. The data type of the address is an array, and the topic is a two-dimensional array. The length of the first dimension is 4, indicating the type of event, and the second dimension is unlimited, indicating the specific event. 26 | 27 | Now let's see how this event is written in. Actually, the main thing is to let the event pass through the bloom filter, and also use the bloom filter to search when looking for it. First, understand a definition. We define every 2048 blocks as a section. Each section corresponds to a key in the section bloom, and the value is a byte array with a length of 2048 * 2048, which is a matrix with an initial value of 0. When stored, it will be compressed with snappy and will be less than 4MB. 28 | 29 | After processing a block, traverse each transaction info in the transaction info list of this block. Each transaction info will have several events, and each event will have addresses and multiple topics. There are at most 4 topics in one event. The following is the data writing. First, generate the sha256 hash value of the address or topic; then apply 3 hash functions to the hash value to get 3 values, and the value range is [0, 2047]; then merge the positions of multiple events in a transaction, and then merge the positions of multiple transactions in a block to complete the writing of event data. 30 | 31 | Suppose the non-zero positions in this block are k0, k1 til km, the section corresponding to the block number is `s`, and the offset corresponding to the block number is f. Then read the bloom k0, bloom k1 til bloom km of section `s` from the database, set the f-th position to 1, and then write it back to the database. Only process the data of solidified blocks. Reading and writing only need one operation. This is the process of event writing. 32 | 33 | Now let's talk about data querying. When querying, a block range is given, and then the combination of address and topic is given, and then all events that meet the conditions are queried. First, calculate the sha256 hash of the address and the sha256 hash of each topic; then apply 3 hash functions to the hash value to get 3 values, and the value range is [0, 2047]. The following is the logical processing. Take the union of the values of the address and the topic. Suppose the positions of non-zero values are p0, p1 til pm; then split it into multiple sections according to the block number range: s, s + 1 til s + n. For section s, find the bitset values corresponding to bloom p0 to bloom pm, and then take the intersection of these m bitsets; suppose there are q non-zero values, that is, q offset blocks. Here, at most 10,000 block numbers are calculated. For the s-th section, the corresponding block number set is 2048 * s + the set of offset values. We take the transaction info list of the block corresponding to 2048 * s + the offset value, traverse the events corresponding to each transaction info, perform an exact match with the query conditions, and then merge and return all the results. If the block number range includes non-solidified blocks, directly read the in-memory data for traversal and matching. The method is the same. This is the whole process of event querying. This logic is actually much more complicated than what I said. Many conditions need to be considered, and it may not be possible to understand it just by looking at the code. 34 | 35 | Now let's talk about the cause of the problem mentioned in the issue. When the contract address is converted to bits by 3 hash functions and then written into the bitset, generally speaking, there will be 3 values after conversion, corresponding to 3 positions. However, there is a very small probability that there may be duplicate values among these three values, that is to say, two or even three of the values are the same, and ultimately there is a certain probability that the written value only occupies 2 or 1 position. However, in the reading logic, the bitset of the contract is forcibly set to 3 different values, and the unassigned ones default to 0, which is inconsistent with the data situation when writing, resulting in the inability to find it, because the length of the non-zero value found may be smaller than 3, which is 1 or 2. This is the cause of this problem. So here, adjust the code. Change the fixed-length data to ArrayList, and convert it to an array after writing the data, and this problem can be solved. 36 | 37 | Actually, it is a very simple problem. Essentially, it is a hash collision problem. Throwing 3 data into a hash bucket with a length of 2048 at the same time, the probability that at least 2 data occupy the same position is easily calculated. The denominator is all the situations, and the numerator is the number of collisions of two values. 38 | 39 | I downloaded the contract library and tried it. I scanned 2.5 million addresses and found that there are about 3,700 contract addresses that will have collision problems, with a probability of 0.148%, that is to say, given an address or topic, the probability of not being able to find it is about 0.148%. Here, everyone can simply understand it. 40 | 41 | Does anyone have any opinions or questions? 42 | 43 | * Jake 44 | 45 | Regarding this problem, what measures should be taken currently? 46 | 47 | * Brown 48 | 49 | It is here, `new int[3]`. Change the array here to an arraylist. Any amount of data can be put into it. In this way, the situation of having 0 value can be completely avoided, and the conditions for writing and querying can be guaranteed to be the same, so that this problem is solved. 50 | 51 | * Jake 52 | 53 | Has this adjustment or measure been finalized? 54 | 55 | * Brown 56 | 57 | Yes, I have tested it and there is no problem. 58 | 59 | * Jake 60 | 61 | Currently, the 0.148% of addresses actually cannot be found under the current logic, because the value after the hash operation is certain, so there will definitely be a collision. Am I understanding correctly? 62 | 63 | * Brown 64 | 65 | Yes, for those 3,700 addresses, no result can be returned under the current code operation. Unless it is a non-solidified block, that is, the event is traversed from the memory, because that does not need to pass through the bloom filter. 66 | 67 | * Jake 68 | 69 | Then there should be no development difficulty. It is a very small adjustment. Is this adjustment expected to go online soon? 70 | 71 | * Brown 72 | 73 | There is currently no clear plan. There is indeed no development difficulty. This problem is not very serious at present. The main thing is that the logic is rather complicated, and it is also very difficult to read the code. But after the problem is clarified, it is actually very simple. The go-live time has not been determined yet. 74 | 75 | * Jake 76 | 77 | OK, thank you. Does anyone else have any questions? 78 | 79 | If there are no questions, today's Community Call is over. Thank you all for your time. Goodbye! 80 | 81 | 82 | 83 | 84 | ### Attendance 85 | * Brown 86 | * Andy 87 | * Allen 88 | * Daniel 89 | * Super 90 | * Murphy 91 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 26.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 26 2 | ### Meeting Date/Time: November 7th, 2024, 6:00-7:00 UTC 3 | ### Meeting Duration: 55 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/104) 5 | ### Agenda 6 | * [ eth_getblockbynumber supports finalized except latest, pending and blocknumber](https://github.com/tronprotocol/java-tron/issues/5953) 7 | * [TIP-697: Migrate Floating-Point Calculations from Math to StrictMath](https://github.com/tronprotocol/tips/issues/697) 8 | 9 | ### Details 10 | * Jake 11 | 12 | Welcome everyone to Core Devs Community Call 26. Today we have two topics to discuss. The first one is about the adjustment of the eth_getblockbynumber interface, which was submitted by Wayne. The second one is an old topic, some updates on the migration of the floating-point operation method in Java-tron. 13 | 14 | Now let's start in order. Wayne, would you like to go first? 15 | 16 | * Wayne 17 | 18 | Okay, just a moment. I can't share my screen. There is a problem. Can anyone help me share it? 19 | 20 | * Jake 21 | 22 | Is it the GitHub issue page that you want to share? I'll do it. 23 | 24 | * Wayne 25 | 26 | Thank you. 27 | 28 | OK, when I am developing, I usually have a need. If I obtain blocks through JSON-RPC, which is the Ethereum interface, currently I can only get the un-solidified blocks, right? Sometimes I want to get the solidified blocks, but currently, the interface level does not support such parameters as the “finalized” parameter in Ethereum. This kind of parameter is not supported in Java-tron. So the idea I want to propose is to support the “finalized” parameter, which is the same as the solidified state in TRON, in the eth_getblockbynumber interface. This is the scenario where I raised this issue. 29 | 30 | The current situation is that I have modified several interfaces. Since TRON does not support the state tree, many interfaces cannot obtain data by block number. So I adjusted the eth_getblockbynumber interface and added this parameter that is equivalent to Ethereum. Later, I discussed with Brown in the community. Brown believes that we should not only adjust one interface. If we want to adjust, we should add similar parameters to all the JSON-RPC interfaces. His reason is that if TRON does not support it at the mechanism level, many times when other interfaces are called, errors will be returned. However, due to the workload of development, currently, we only consider adjusting the three interfaces of eth_getBlockByNumber, eth_getBlockTransactionCountByNumber, and eth_getLogs. The implementation logic is the same. By recognizing the “finalized” parameter, we can get the corresponding data of the solidified block. For other interfaces, such as obtaining the balance by specifying the block number, I did not make any adjustments. I just let them return an error when they recognize the finalized parameter. This is roughly the implementation of this issue. Do you have any questions? 31 | 32 | * Jake 33 | 34 | What do you think of this implementation, guys? 35 | 36 | Wayne, I have a question. Regarding this issue, do you have any other materials to supplement? On the GitHub issue, that is, the page we are looking at now, there is very little information. For example, the content in the specification and subsequent paragraphs has not been filled in yet. 37 | 38 | * Wayne 39 | 40 | Well, a lot of content is discussed in the comments section below. Brown's suggestions are also in the comments section. 41 | 42 | * Jake 43 | 44 | So is the implementation plan basically determined now? 45 | 46 | * Wayne 47 | 48 | Yes, it is almost determined. There are no other problems. 49 | 50 | * Jake 51 | 52 | Then please explain the detailed implementation approach and the scope of the adjusted interfaces in the specification. 53 | 54 | * Wayne 55 | 56 | Okay, I will fill it in later. I will list the content I just talked about in this issue. 57 | 58 | * Jake 59 | 60 | Okay. Many people will check the issue page. If it is not listed and people are trying to learn the issue in advance, like in today's meeting, it will take them some time to understand the specific content, and they may not be able to raise any questions for a while. 61 | 62 | * Wayne 63 | 64 | I understand. After I fill in the content, everyone can discuss further under the issue further. 65 | 66 | * Jake 67 | 68 | Any other questions? If there are no questions, let's move on to the next topic. Boson, would you like to update us on the situation of the calculation method migration? 69 | 70 | * Boson 71 | 72 | Okay, just a moment. Let me share my screen. 73 | 74 | This topic has been mentioned before. Now I have organized it into a TIP. Let's take a look. Let me briefly introduce it. Up to the v4.7.6 version, Java-tron has been using the java.lang.Math class for floating-point calculations. The java.lang.Math class may have different calculation results for the same input on different hardware platforms and different JDK versions. So far, all versions of Java-tron only support the JDK8 and x86 environments, and there will be no data inconsistency due to the java.lang.Math class. Previously, when upgrading to JDK11, in the attempt on the ARM architecture, a database inconsistency was found. The specific problem was caused by the floating-point operation result of Math. If Java-tron considers supporting cross-platform and more JDK versions in the future, then it needs to replace the java.lang.Math class with the java.lang.StrictMath class, which has consistent calculation results on cross-platform and higher JDK versions. 75 | 76 | The following is a list of all the methods of the Math class used in TRON, such as pow, ceil, round, min, max, signum, abs, and the int type methods addExact, floorDiv, multiplyExact, subtractExact. Among all the calculation types used in TRON, only the calculation result of pow will be inconsistent in a cross-platform environment. 77 | 78 | There are two scenarios where the results are inconsistent, which have been mentioned before. For example, in the Bancor transaction, the calculation of the 2000th power and the 2000th root. The other one is in the dynamic energy model, there is a decay model, which also uses pow. Currently, it is considered to replace these two methods through a proposal. 79 | 80 | I also did tests in these two scenarios. In the Bancor transaction, we can see here that when doing the square root operation, Math is faster and has better performance than StrictMath; but when doing the power operation, StrictMath is still faster than Math. The unit here is nanoseconds. For TRON's millisecond-level transactions, the impact can be ignored. Moreover, for the comprehensive performance of the power and square root operations, their operation times can cancel each other out. The difference between the two methods is 300 nanoseconds, one positive and one negative. So for the Bancor transaction scenario, there is no performance loss. 81 | 82 | For the dynamic energy model scenario, the contract will only call this method once within a maintenance period, which is 6 hours. The frequency is extremely low. The power value of the operation is equal to the number of rounds of the current maintenance period when calling the contract minus the number of rounds of the maintenance period when the last time calling the contract. That is to say, for a popular contract being called each maintenance period, the power value of this operation is 1. In this case, let's look at the performance test. Only in the first maintenance period, the performance of Math is higher than that of StrictMath. From the second maintenance period onwards, the performance of StrictMath is better than Math's. The operation time of Math.pow is 75 nanoseconds, while StrictMath.pow only needs 17 nanoseconds. These are all nanosecond-level differences, and for the overall transaction performance, it can be said that there is no impact. 83 | 84 | That's about it. Do you have any ideas? 85 | 86 | * Lucas 87 | 88 | Does this change need to be implemented through a proposal? 89 | 90 | * Boson 91 | 92 | Yes, it is necessary. Because the calculation results are inconsistent, it will be a hard fork. This is a change to the calculation logic and requires a proposal. If this proposal is passed, then Java-tron will theoretically be able to support versions after JDK8 and the ARM architecture. 93 | 94 | * Ray 95 | 96 | I have a question. How can we be sure that using the StrictMath method can ensure completely consistent calculation results across platforms? 97 | 98 | * Boson 99 | 100 | This is clearly stated in the Java official documentation. We have also done verification tests, and there is no problem. In fact, the results of basic operations are the same between Math and StrictMath. Only the complex operation of pow in TRON will have inconsistent results. 101 | 102 | * Brown 103 | 104 | So after that, the newly written code cannot use Math anymore, right? 105 | 106 | * Boson 107 | 108 | Yes. After the proposal is passed, new development and code should use the StrictMath class. 109 | 110 | * Brown 111 | 112 | In fact, only the consensus part that needs to be written to the database must use StrictMath. It doesn't matter if Math is used in other parts. 113 | 114 | * Boson 115 | 116 | What is the significance of having to use Math in those scenarios? If the proposal is passed, I suggest using StrictMath whenever possible. This also makes the code more standardized and unified. 117 | 118 | * Allen 119 | 120 | I also have a question. Maybe I didn't hear clearly. Math.pow has different calculation results on different architecture platforms, right? 121 | 122 | * Boson 123 | 124 | Not only among different architectures but also among different JDK versions. 125 | 126 | * Allen 127 | 128 | So are the calculation results of these two methods the same on the same JDK version and platform? 129 | 130 | * Boson 131 | 132 | On the JDK8 version and X86 platform, the results are also inconsistent. 133 | 134 | Any other questions? 135 | 136 | * Jake 137 | 138 | Does anyone else have any questions? 139 | 140 | Regarding the adjustment of the JSON-RPC interfaces, Brown, do you have anything to add? You participated a lot in the GitHub discussion before. 141 | 142 | * Brown 143 | 144 | Trongrid currently only opens the 8545 port. The other ports, 8555 and 8565, are not supported, right? 145 | 146 | * Boson 147 | 148 | There is no need to open so many ports. 149 | 150 | * Wayne 151 | 152 | Yes, opening too many ports will confuse developers and is not user-friendly. 153 | 154 | * Brown 155 | 156 | I just want to make sure that after the development is completed, the ports on the client side and the service provider side are the same, and there are no omissions that might cause errors. 157 | 158 | * Ray 159 | 160 | I think if we want to adjust the JSON-RPC interface, we should follow the principle of being compatible with Ethereum. Because Ethereum uses only that one port, so TRON should also be compatible with it in the design. We can use only one port and distinguish the states with parameters. Don't open multiple ports. This does not conform to the design principle of TRON. 161 | 162 | * Wayne 163 | 164 | Yes, currently we do not consider using ports other than 8545. 165 | 166 | * Boson 167 | 168 | One more question, Java-tron currently does not support the pending state, right? 169 | 170 | * Wayne 171 | 172 | Yes, TRON does not support the earliest and pending states because TRON does not have a state tree. The pending state in TRON refers to the transactions in the pending pool. 173 | 174 | * Boson 175 | 176 | So what are the pending and latest states in Ethereum like? 177 | 178 | * Wayne 179 | 180 | In Ethereum, the latest transaction state means that this transaction has been executed locally, and since it is in a distributed network, it has not reached a consensus and there is a possibility of being rolled back. This is my understanding. And the transactions in the pending pool have not been executed yet. 181 | 182 | * Boson 183 | 184 | This is indeed different from the pending state in TRON. In the TRON network, the transactions in the pending pool have all been executed, but they have not been packaged yet, so they are placed in the pending pool. That is to say, the latest state in Ethereum corresponds to the pending state in TRON. 185 | 186 | * Wayne 187 | 188 | Most likely, that is the case. 189 | 190 | * Brown 191 | 192 | This issue still needs to be evaluated. It is currently in a relatively initial state, and it is not certain when it can be launched. 193 | 194 | * Jake 195 | 196 | Any other questions? 197 | 198 | That's all for today. Thank you all for your time. Goodbye! 199 | 200 | 201 | 202 | 203 | ### Attendance 204 | * Brown 205 | * Andy 206 | * Allen 207 | * Daniel 208 | * Lucas 209 | * Wayne 210 | * Boson 211 | * Federico 212 | * Ray 213 | * Aaron 214 | * Super 215 | * Murphy 216 | * Jake 217 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 28.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 28 2 | ### Meeting Date/Time: December 5th, 2024, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/106) 5 | ### Agenda 6 | * [Introduce delegating resource usage right](https://github.com/tronprotocol/tips/issues/671) 7 | * [TIP-697: Migrate Floating-Point Calculations from Math to StrictMath](https://github.com/tronprotocol/tips/issues/697) 8 | * Mechanism Discussion of Permission Management 9 | 10 | ### Details 11 | 12 | * Jake 13 | 14 | Today we are having Core Devs Community Call 28. We have three topics to discuss, and we've added one more topic temporarily, which was submitted by Brown. We will discuss that later. 15 | 16 | Let's follow the agenda and start with the first topic. Who is the submitter of this topic? Are they in the meeting? 17 | 18 | * Murphy 19 | 20 | I will be presenting this topic. This request was proposed based on feedback I gathered from the community. 21 | 22 | * Jake 23 | 24 | Alright, go ahead! 25 | 26 | * Murphy 27 | 28 | Boson, are you here? If you have something urgent, you can present the second topic instead since you submitted it. 29 | 30 | * Boson 31 | 32 | I'm good, we can go in order. Go ahead. 33 | 34 | **Introduce Delegating Resource Usage Right** 35 | 36 | * Murphy 37 | 38 | The topic is "Introduce Delegating Resource Usage Right." This was a request from a project in the community that wants to introduce a new mechanism on TRON called the "resource usage right." 39 | 40 | Let me explain this with an example. They want to address A to delegate X amount of energy to address B. In essence, it’s delegating the resource usage right. After delegation, the energy still remains in address A, but the usage right is given to B. When address B needs to use the energy, if the energy usage is within the delegated amount, it will be deducted from address A directly. If the usage exceeds the delegated limit, the excess will be consumed from address B’s energy. This was the initial idea—to introduce this resource usage right mechanism. I briefly discussed this with Daniel earlier, and it involves changes to the underlying logic of TRON, which would be difficult to implement. Therefore, the team hoped the developers could consider the technical challenges more deeply. Recently, the project team asked for progress updates, so I explained the situation to them. Now, we have a new plan using a multi-signature approach to create a new type of transaction and aggregate transactions using multi-sig. When making the transaction, they can specify which address in the multi-sig wallet should consume the energy. This plan seems feasible, so I wanted to bring it up in today’s meeting to see if the approach they want is viable. If it is, we can discuss how to proceed. 41 | 42 | * Jake 43 | 44 | Murphy explained it very clearly. Does anyone have any thoughts? Feel free to share, and it’s not limited to these two options. 45 | 46 | * Aaron 47 | 48 | I have a question. If the multi-sig option is used, does that mean every transaction requires the signature of the energy owner? 49 | 50 | * Murphy 51 | 52 | Yes, mainly the private keys for hot wallet addresses. 53 | 54 | * Aaron 55 | 56 | Does this resemble the current delegate and undelegate process? They would need to sign for each transaction, but if they need to aggregate transactions, it doesn’t seem to save much in terms of operations. 57 | 58 | * Murphy 59 | 60 | The goal is that the project team needs to aggregate energy payments for transactions and directly specify which main hot wallet address will consume the energy. If the previous method was used, the project team would first need to delegate, then the sub-address would perform a transfer transaction, and the main address would later undelegate. At least three transactions are required to complete the aggregation. Because there are many addresses, the process becomes time-consuming. The core issue from the community’s perspective is that the whole process is too cumbersome. 61 | 62 | * Aaron 63 | 64 | I understand now. I thought of a zero-gas platform built by another team, and this solution might be suitable for the situation. It essentially doesn't require many changes to TRON. Instead, an external platform could use a script to complete the aggregation. This would be like using a script to automate the previous three steps and avoid redundant operations while ensuring that the energy consumption is handled by the same main address. 65 | 66 | * Murphy 67 | 68 | I’m not familiar with the zero-gas platform in detail, but is the functionality similar? If so, Aaron, could you comment on this issue and briefly describe this solution? 69 | 70 | * Aaron 71 | 72 | Sure. Actually, it's not an on-chain platform but a centralized one. Let’s see how the community responds to this solution and how the project team accepts it. One other point I want to mention is that, based on Murphy’s new plan, adding a new transaction type might not fully meet the project team’s needs. I think they’re looking for something similar to exchange aggregation actions, which might involve TRX and USDT, right? 73 | 74 | * Murphy 75 | 76 | Yes, both TRC-10 and TRC-20 are involved. 77 | 78 | * Aaron 79 | 80 | Then there could be more complex operations like calling smart contracts during aggregation. Adding a new transaction type might not meet the project team's needs. So, I think a standalone platform, designed externally to minimize chain-side development requirements, would be a better solution. 81 | 82 | * Jake 83 | 84 | Okay, if there are no more questions, let’s move on to the next topic. Boson will update us on the latest progress regarding the migration of calculation methods. 85 | 86 | **TIP-697: Migrate Floating-Point Calculations from Math to StrictMath** 87 | 88 | * Boson 89 | 90 | Can everyone see my screen? I’ll give a brief update on the current situation. The migration of the pow floating-point calculation method has been included in version 4.7.7 and can be activated through a proposal. This TIP is divided into two stages: 91 | 92 | * Stage 1: Migrate the pow operation from `java.lang.Math` to `java.lang.StrictMath`. 93 | * Stage 2: Migrate all other operations from `java.lang.Math` to `java.lang.StrictMath`. 94 | 95 | Afterward, the TRON development code will no longer allow using Math for numerical calculations. 96 | 97 | After statistics, we found that operations using Math still exist in the list. These operations include addition, subtraction, multiplication, and division, which don’t involve floating-point operations, so the results are the same as StrictMath. The other operations like `max`, `min`, `signum`, `round`, `abs`, `random`, and `ceil` also have results identical to those of strictMath, although some of them may still be internally called Math methods. The only operation that differs is `pow`, which has already been migrated to StrictMath. Some pow operations in TRON are still not replaced because they are integer power calculations, and their results are identical. 98 | 99 | Stage 2 is to directly replace these operations in the next version without needing a proposal. The implementation includes a `strictMathWrapper` that unifies the calls to strictMath. We are also using GitHub Actions, which checks every commit to see if Math is used, and if so, the CI will throw an error. That's the current plan, and any thoughts on this TIP? 100 | 101 | * Jake 102 | 103 | I have a question: Do Stage 1 and Stage 2 have a specific timeline? 104 | 105 | * Boson 106 | 107 | Stage 1 has already been included in version 4.7.7. Stage 2 is planned to be included in the next major version. 108 | 109 | * Brown 110 | 111 | Since the calculation results of all methods except `pow` are the same, why do we need to migrate everything to StrictMath? Why not just leave Math for those who don't have differences? 112 | 113 | * Boson 114 | 115 | Let me explain. While the results of all methods except `pow` are currently the same between Math and strictMath, there’s no guarantee that they will remain consistent in the future. Some of the calculations in Math can be implemented using native code, such as `ceil`. But strictMath has fixed implementations, ensuring consistent results. If we don’t unify under strictMath, we might face inconsistencies in the future as new features are added. Mixing the two could lead to potential calculation discrepancies. 116 | 117 | Ethereum clients, for example, use `big int` for all calculations and avoid floating-point calculations at the lowest level, ensuring consistency. 118 | 119 | * Jake 120 | 121 | Boson’s point is that unifying the calculation methods ensures we avoid potential inconsistencies in the future. 122 | 123 | * Boson 124 | 125 | Exactly, it eliminates that issue. Any further questions? 126 | 127 | * Jake 128 | 129 | If not, let’s move on to the next topic. This one was submitted by Brown. 130 | 131 | **Mechanism Discussion of Permission Management** 132 | 133 | * Brown 134 | 135 | Today, I want to use the opportunity to discuss Ethereum's Geth interface permission management mechanism to explore how we should implement interface permission management for TRON in the future. Currently, Java-tron does not have this functionality, but it's quite necessary to implement it. 136 | 137 | Java-tron currently manages interface access through port differentiation, while Ethereum's Geth controls different functionalities through different namespaces. Here's an overview of Geth's interface permission management mechanism. 138 | 139 | The first mechanism is access restriction, which allows access only from specific IP addresses. In Geth, this is implemented by specifying IPs during node startup, using the `--http.addr` and `--http.port` parameters to restrict HTTP-RPC service access. This ensures that remote hosts cannot access it directly. Additionally, allowed domains can be specified using the`--http.corsdomain` parameter to restrict access to the RPC from certain domains. 140 | 141 | The second mechanism is enabling and disabling specific modules. Using the `--http.api` and `--ws.api` parameters, you can specify which modules are enabled, preventing the exposure of sensitive modules. For example, only the `eth` and `net` modules can be enabled. In terms of API modules, a namespace is a space to categorize APIs; a service hosts these namespaces, and multiple namespaces can be grouped under one service. The authenticated field indicates whether an API requires authentication before it can be accessed. Some fields like `version` and `public` are deprecated now. Geth has several modules, such as `admin`, `debug`, `eth`, `les`, `net`, etc. Some modules, like `personal` and `miner`, have been deprecated. 142 | 143 | The third mechanism is JWT authentication (JSON Web Token). To use Geth's authenticated APIs, a `--authrpc.jwtsecret` parameter can specify the JWT secret key file (in hexadecimal format) for verification. Without this secret, access to these APIs will be denied. Since Ethereum nodes may expose JSON-RPC APIs that allow users to interact with the blockchain, JWT can prevent unauthorized access. With the JWT secret, we can ensure that only authorized parties can generate valid JWTs, preventing man-in-the-middle attacks or data tampering. 144 | 145 | The above three mechanisms are some of the key features of Geth. Other mechanisms, such as logging, firewall settings, and HTTPS, are more similar to Java-tron, so they are not the main focus of this discussion. 146 | 147 | To summarize: Geth controls the accessibility of APIs and namespaces during node startup using the `--http.api` parameter; each API/namespace corresponds to a service, which may contain multiple APIs; the same port is used for all HTTP/JSON-RPC services; IP or domain access restrictions can be set; JWT secrets can be used for API authorization, ensuring that only authorized users can access certain APIs. 148 | 149 | For Java-tron, we can take inspiration from Ethereum's methods by dynamically maintaining IP blacklists and whitelists or controlling access based on time parameters during virtual execution. We can also add extra validation steps during interface access to achieve similar results. That's pretty much the gist of it. Any ideas? 150 | 151 | * Jake 152 | 153 | Brown, this hasn't been posted on GitHub yet, right? If it's for open discussion, once you have a concrete proposal, please post it as soon as possible so the community can discuss it. 154 | 155 | * Brown 156 | 157 | I understand. This is just a preliminary investigation to see how others have done it, and I’ll organize a more concrete plan and post it for discussion later. 158 | 159 | * Allen 160 | 161 | Can you give an example of how identity verification is done? At which stages? 162 | 163 | * Brown 164 | 165 | Are you referring to JWT? This hasn't been fully considered yet, but it's an open standard, and there are many examples. It's not difficult to implement. 166 | 167 | * Andy 168 | 169 | I remember that in Ethereum when deploying consensus layer and execution layer clients, they used JWT for authentication between them. 170 | 171 | * Allen 172 | 173 | Besides IP restrictions and JWT, how is module restriction implemented? 174 | 175 | * Brown 176 | 177 | It is like the code is running, but access to the corresponding module or private spaces is restricted. The module itself is operational, but certain parts are inaccessible. 178 | 179 | * Andy 180 | 181 | Can Ethereum clients also restrict which specific methods in a module can be called, and which cannot? Can it be that granular? 182 | 183 | * Brown 184 | 185 | It seems not. The granularity is usually limited to module-level access control, not down to individual method calls. 186 | 187 | * Jake 188 | 189 | Please post it as soon as you have a clearer direction. 190 | 191 | * Brown 192 | 193 | Got it. I’ll move forward with that. 194 | 195 | * Jake 196 | 197 | Any other thoughts? If not, let’s wrap up today’s meeting. Goodbye, everyone! 198 | 199 | 200 | 201 | ### Attendance 202 | * Brown 203 | * Andy 204 | * Allen 205 | * Boson 206 | * Daniel 207 | * Lucas 208 | * Ray 209 | * Aaron 210 | * Super 211 | * Murphy 212 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 29.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 29 2 | ### Meeting Date/Time: December 19th, 2024, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/107) 5 | ### Agenda 6 | * Upgrade Mockito and Replace PowerMock 7 | * [Optimize System.exit Usage](https://github.com/tronprotocol/java-tron/issues/6125) 8 | 9 | ### Details 10 | 11 | * Jake 12 | 13 | Hi everyone, we’ve got a couple of newcomers from the community today, and we have two topics to cover. One is Upgrade Mockito and Replace PowerMock, and the other is Optimize System.exit Usage. 14 | 15 | Super, are you ready to share with us? 16 | 17 | * Super 18 | 19 | No problem, I’ll go now. Can you see my screen? 20 | 21 | * Jake 22 | 23 | You're good to go. 24 | 25 | **Upgrade Mockito and Replace PowerMock** 26 | 27 | * Super 28 | 29 | So here’s the background on this topic: When we were using PowerMock, it was really convenient to mock static methods and constructors using `mockStatic` and `whenNew`. However, after upgrading the JDK, I found that PowerMock is no longer being maintained and doesn’t support JDK 17. After doing some research, I found that Mockito can replace PowerMock. 30 | 31 | This issue is about upgrading to a higher version of Mockito, specifically using `Mockito.mockStatic` and `Mockito.mockConstruction` to meet our needs, including constructor mocking. 32 | 33 | Looking into it, Mockito’s advanced versions, 4.0 and above, are split into two modules: mockito-core and mockito-inline. The core module covers most of the common Java testing scenarios, and it’s suitable for mocking regular classes and interfaces. If there are no special requirements, just using mockito-core should work fine for us. 34 | 35 | On the other hand, the inline module is for more special cases, like mocking static methods, constructors, and final classes.One thing to note: starting from version 5.0, the inline features have been merged into the core module, so for Java-tron, the core module alone can meet our requirements. However, version 5.0 only supports JDK 11 and above, and we still need to support JDK 8 in our project, so we can’t use version 5.0 directly. That’s why this issue is based on Mockito 4.0. 36 | 37 | Boson, do you have any thoughts on this? 38 | 39 | * Boson 40 | 41 | No issues here. I was planning to upgrade PowerMock as part of the JDK 17 upgrade anyway, so since you’ve already looked into this, I can focus on other tasks. 42 | 43 | * Super 44 | 45 | Great, I’ve already done some testing. Although Mockito can replace PowerMock, it’s not super friendly for mocking private methods. Mockito doesn’t support private methods directly, so we’d have to use reflection to call them. Alternatively, we can rethink the approach. Usually, private methods have a public entry point, and private variables can be set via reflection. Even with the upgraded version of Mockito, it doesn’t fully support private methods. But for mockStatic, mockConstruction, and final class support, it works well. 46 | 47 | One concern is that if Java-tron uses Mockito’s inline module, it could impact overall performance because it involves bytecode manipulation. I ran some tests, and it wasn’t too bad—running 2120 unit tests went from 22 minutes to just over 23 minutes, which is still acceptable. Test coverage also improved to over 70%, adding 700+ lines of code coverage based on the pull request I submitted. 48 | 49 | To summarize the versioning: Mockito 4.0 supports JDK 8 to JDK 17, while version 5.0 only supports JDK 11 and above. All the discussion above is based on Mockito 4.0. Any questions from anyone? 50 | 51 | * Boson 52 | 53 | No other questions for now. After this feature is live, we’ll probably stop using Spring-based test startup, right? 54 | 55 | * Super 56 | 57 | Yes. There are two aspects to consider here: one is service startup. We’ll need to improve this since many places in the code start services, and the ports they use clash, causing some services to fail to start. The other aspect is with databases, many test cases use `openDatabase`, and if we use mocks instead, the performance would improve significantly, making the tests run faster. 58 | 59 | Since there’s too much legacy code to modify, it’ll be more of an ongoing process, with people adjusting as they go. But I think around 24 minutes for the tests is still acceptable. 60 | 61 | * Boson 62 | 63 | Is there a plan to improve CI performance and bring the build time under 15 minutes? 64 | 65 | * Super 66 | 67 | That would go hand-in-hand with the parallel execution of unit tests we discussed earlier. 68 | 69 | * Boson 70 | 71 | Here’s the thing: there are about 2000 tests now, and a lot of them are repetitive. For example, many database-related tests are covered across different services, so removing those redundant tests could help lower the execution time. 72 | 73 | * Super 74 | 75 | The redundancy issue isn’t fully clear yet. After the Mockito upgrade, many of the test cases will need some adjustments. But as long as we keep parallel execution, we should be able to bring the time down to around 15 minutes. If we also remove the duplicate tests, we should be able to keep it under 15 minutes. 76 | 77 | By the way, you mentioned there’s an issue with test run times being really long on Mac OS, what was that about? 78 | 79 | * Boson 80 | 81 | That issue only happens with Mac OS 12. After upgrading to version 14 or 15, it’s fine. 82 | 83 | * Super 84 | 85 | Alright, so it’s not related to our current work. This feature should be included in version 4.8.0. I’ve already submitted the PR. If there are no more questions, I’ll wrap up my part. 86 | 87 | * Boson 88 | 89 | Okay, I’ll start sharing then. 90 | 91 | * Jake 92 | 93 | Sounds good! 94 | 95 | **Optimize System.exit Usage** 96 | 97 | * Boson 98 | 99 | My topic is pretty simple. It's about optimizing the use of `System.exit` in the system. Currently, there are several cases where `System.exit` is called directly to shut down the system after encountering specific exceptions. While this approach is straightforward, it leads to a few technical debts: 100 | 1. Poor maintainability: Scattered `System.exit` calls make it hard to trace and maintain the program flow. 101 | 2. Testing issues: Code with `System.exit` is hard to unit test because it causes Gradle tests to unexpectedly terminate, which messes up code coverage stats and reduces the reliability and stability of CI. 102 | 3. Resource cleanup risks: `System.exit` doesn’t run finally blocks, meaning resources like database connections or file handles might not get closed properly. 103 | 104 | Right now in TRON, there are a dozen places where `System.exit` is used to exit the system. The problem with this command is that it doesn’t collect any information and exits immediately, so it’s difficult to trace the exit reason in the stack trace. 105 | 106 | The improvement I propose is to replace `System.exit` with throwing an error instead. So, whenever the system would have called `System.exit`, it should throw an error instead. Then, at the top level, we can have a unified exit logic based on that error. This makes it much easier to test the business logic. 107 | 108 | In terms of design, I suggest using errors instead of exceptions. For example, we could have a `TronError` as the base class with several subclasses based on the places where we’ve identified the need to exit. Some examples are `ConfigurationError`, `DatabaseError`, `EventSubscribeError`, and `OtherError`. Once we have these errors categorized, we can throw the appropriate error at the places where we previously had `System.exit`, and then exit from there. 109 | 110 | Previously, when we encountered `System.exit` in tests, we would use a JAR to intercept it. But this JAR is no longer supported in JDK 17, so solving the `System.exit` problem is essential if we want to upgrade to JDK 17. 111 | 112 | After making these changes, there are a few exceptions we need to be aware of. The first is when argument parsing fails, such as during SR node startup with keystore file. In the old setup, the main process would exit, but now we throw a `ConfigurationError` and then exit, so this behavior is consistent with before. We’ll need to track this further. 113 | 114 | Another issue happens during Spring initialization when errors are thrown, like `ConfigurationError` or `DatabaseError`, and it leaves two leftover processes called Thread-3 and leveldb. We haven’t pinpointed the exact cause of this yet, so we’ll need to track it as well. 115 | 116 | That’s about it. Any questions? 117 | 118 | * Andy 119 | 120 | So, your solution is essentially wrapping all those scattered `System.exit` calls into different error types. You throw an error, and instead of immediately handling it, you let it propagate to the top level where you have a unified exit logic, right? And where exactly does the exit logic happen? 121 | 122 | * Boson 123 | 124 | Yes, that’s correct. There’s a global thread handler for handling exits, kind of like a listener. If we don’t use that, we’ll need to design a new global handler for the errors. 125 | 126 | * Andy 127 | 128 | I understand now that you're handling `System.exit`, which isn't part of the business logic, at the top level. You don’t need to include any business-specific details, just check for the error and exit accordingly. 129 | 130 | * Boson 131 | 132 | Right, there won’t be any new logic. We’ll just change where the exit happens, but the exit itself remains the same. The exit will still occur, but now it will happen at the top level if it’s not handled by any lower layers. However, as I mentioned, there are still two threads `Thread-3` and `leveldb` created during Spring initialization that are causing issues when trying to exit. We still need to figure out the cause of those. 133 | 134 | * Ray 135 | 136 | Are you concerned about those two threads because they’re preventing a clean exit? 137 | 138 | * Boson 139 | 140 | Yes, that’s the issue. 141 | 142 | * Ray 143 | 144 | Earlier, you were talking about throwing errors and then handling the exit logic yourself, but I was wondering if you’re still relying on the JVM’s exception handling to exit automatically? I’m not sure which option you’re going with. If you choose the first one, where you handle the exit yourself, would the daemon threads still cause issues? 145 | 146 | * Boson 147 | 148 | Yes, I’m still proposing that we handle the exit manually. The issue is that the leftover daemon threads prevent a clean exit, so we’ll still need to use a similar approach to the one we have now to handle the shutdown process. 149 | 150 | * Lucas 151 | 152 | So, the plan is to throw errors up to the top level and let that handle the exit? How do you ensure that the top-level entry point is in the right place? 153 | 154 | * Boson 155 | 156 | I’ve traced it in the stack trace. I’ll list all the places where this happens in the issue for everyone to review and check for any mistakes. For example, during the startup phase, we throw the error directly in the main method. In other cases, like transaction processing, the logic is divided into layers like the interface layer, P2P layer, and repush layer. Block processing also has various threads for block production, syncing blocks, and processing messages via P2P. 157 | 158 | * Lucas 159 | 160 | So, Spring initialization errors will be thrown to main, right? 161 | 162 | * Boson 163 | 164 | Yes, exactly. Since Spring is running in the main thread, any errors there will go directly to main. Other errors will be thrown to their respective layers or threads. 165 | 166 | * Ray 167 | 168 | When you throw errors to the top level, what exactly do you mean by "top level"? Is there a chance that these errors could be caught elsewhere before they reach the top level? 169 | 170 | * Boson 171 | 172 | I’ve identified the top level based on the stack trace, it’s where the thread starts, so it’s a clear entry point for the errors. 173 | 174 | * Lucas 175 | 176 | If you stick with the original `System.exit` approach, there wouldn’t really be any significant impact, right? 177 | 178 | * Boson 179 | 180 | Correct, there wouldn’t be any immediate impact. The real issue is that this approach is a bad coding practice. We shouldn’t be exiting directly in the middle of business logic. Instead, errors should be propagated up the stack. 181 | 182 | * Lucas 183 | 184 | Would it be better to define a new enum instead of using multiple error subclasses? I think defining 12 different error types is a bit much. We could just define a single type or description for each case, so instead of 12 subclasses, we’d have 12 different descriptions. 185 | 186 | * Boson 187 | 188 | What do you all think? 189 | 190 | * Andy 191 | 192 | You could include the exit code and description in the enum. That might simplify things. 193 | 194 | * Boson 195 | 196 | That’s a good point. We don’t need to define so many error types. Let's stick with the plan: Step 1, throw errors to the top level; Step 2, during the next developer meeting, we can discuss whether we really need to exit at those points in the code. 197 | 198 | The root cause of this issue is really poor coding practices. Directly exiting within threads is just not a good design. We shouldn’t be calling `System.exit` in the middle of business logic, that is, it should be thrown up to higher levels. 199 | 200 | One of the teams from community has already pointed this out and requested that the fix be submitted to the dev branch as soon as possible. 201 | 202 | * Jake 203 | 204 | So there's no question about whether we should do this, it needs to be done, and we need to get it live in the next release, right? 205 | 206 | * Boson 207 | 208 | Exactly. Any other questions? 209 | 210 | * Jake 211 | 212 | No? Then we’ll wrap up here. Thanks, everyone! 213 | 214 | 215 | 216 | ### Attendance 217 | * Brown 218 | * Andy 219 | * Sunny 220 | * Federico 221 | * Allen 222 | * Boson 223 | * Daniel 224 | * Lucas 225 | * Ray 226 | * SunnyBella 227 | * Aaron 228 | * Super 229 | * Murphy 230 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 35.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 35 2 | ### Meeting Date/Time: April 18th, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/121) 5 | ### Agenda 6 | Ethereum Cancun Upgrade Support 7 | * [TIP-650: Implement EIP-1153 Transient Storage Instructions](https://github.com/tronprotocol/tips/blob/master/tip-650.md) 8 | * [TIP-651: Implement EIP-5656 MCOPY - Memory Copying Instruction](https://github.com/tronprotocol/tips/blob/master/tip-651.md) 9 | * [TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction](https://github.com/tronprotocol/tips/blob/master/tip-745.md) 10 | 11 | Enhanced Consensus Layer Verification 12 | * [TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer](https://github.com/tronprotocol/tips/blob/master/tip-694.md) 13 | 14 | Optimized Block Synchronization Logic 15 | * [Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth](https://github.com/tronprotocol/java-tron/pull/6184) 16 | * [Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions](https://github.com/tronprotocol/java-tron/pull/6181) 17 | 18 | Other Changes 19 | * [Enhanced Event Service Framework (V2.0) Provision](https://github.com/tronprotocol/java-tron/issues/6153) 20 | * [TIP-697: Cross-Platform Consistent java.strictMath Replacement for java.math](https://github.com/tronprotocol/tips/blob/master/tip-697.md) 21 | 22 | API 23 | * [Enhanced Compatibility for Ethereum JSON-RPC Interface](https://github.com/tronprotocol/java-tron/issues/5953) 24 | 25 | ### Detail 26 | 27 | * Jake 28 | 29 | Hello, everyone. Today's Core Devs Community Call will mainly focus on the upcoming release of GreatVoyage-v4.8.0 (Kant). In the previous meetings, these contents have been fully discussed and the development tasks have been basically completed. So today, I'd like each developer to briefly introduce the update contents and the situation after the final adjustments before the release. 30 | 31 | Let's start with TIP-650, TIP-651 and TIP-745 first. Raymond, are you ready? 32 | 33 | **Ethereum Cancun Upgrade Support** 34 | 35 | * Raymond 36 | 37 | First of all, TIP-650 is to implement the transient storage of Ethereum EIP-1153. To put it simply, this feature is a new type of storage method within transaction execution. After the transaction is completed, the stored data will get disposed instead of persistent storage. Currently, the TIP has been updated to the 'final' status and has been merged into the TIP master branch of Java-tron. 38 | 39 | The second one, TIP-651, implements a new instruction for memory copying in EIP-5656. The main function of this instruction is to copy a segment of data from a certain position in the memory to a new position, and a new instruction called `M COPY` is introduced. Currently, the code of this TIP has also been merged into the master branch, and the status of the TIP has been changed to 'final'. 40 | 41 | Finally, TIP-745 introduces the instructions of Ethereum EIP-4844 and 7516, mainly two instructions `BLOBHASH`and `BLOBBASEFEE`. In fact, EIP-4844 also introduced blob transactions and a precompiled contract. Currently, this TIP has made some functional modifications, removing the previous kzg precompiled contract and only retaining these two instructions. So it means that it is not a complete implementation of EIP-4844, and it does not implement the blob transaction and the precompiled contract. The functions of these two instructions are not complete at present. Currently, these two instructions only return a default value of '0', mainly serving as a compatibility placeholder. And currently, the status of the TIP has also been changed to final and merged into the master branch. 42 | 43 | * Benson 44 | 45 | I have a question. Except for 745, there are no changes in the other two TIPs compared with before, right? 46 | 47 | * Raymond 48 | 49 | Yes, only 745 has been slightly modified. We will not implement that precompiled contract for now. 50 | 51 | * Jake 52 | 53 | If there are no other questions, let's move on to the next one. 54 | 55 | Daniel, could you please share the situation of TIP-694? 56 | 57 | **Enhanced Consensus Layer Verification** 58 | 59 | * Daniel 60 | 61 | OK, regarding TIP-694, it is a TIP that strengthens the transaction verification in the consensus stage. At the end of 2024, the transaction verification was optimized during the transaction broadcasting stage. And now we plan to optimize the verification at the consensus level as well, mainly to prevent the situation of block-producing nodes acting maliciously. It is mainly divided into four scenarios. The first one is to limit the scale of account creation transactions. The second one is to strengthen the size of critical transactions to avoid transactions within the block exceeding the maximum transaction limit. The third one is to limit the length of the transaction result list. The fourth one is to make the restrictions on expiring transactions stricter. This change is relatively simple. It was also mentioned in the previous developer meetings. It is mainly extended from the original broadcasting stage to the consensus level, which can be regarded as an improvement. This TIP has also entered the 'final' status. Do you have any questions? 62 | 63 | * Jake 64 | 65 | OK, if there are no other updates and questions, let's move on to the next one. Lucas, please tell us about it. 66 | 67 | **Optimization P2P and Event Service** 68 | 69 | * Lucas 70 | 71 | Pull 6184 is to discard the block list below the solidified block. A problem was previously raised that if users broadcast some historical block lists and then the nodes fetch them, it will occupy network bandwidth and some other resources. Because these historical transaction blocks already exist, it is not easy to make judgments through transactions currently. Here, the optimization is mainly aimed at the blocks. Since the block list contains the block height, and the blocks below the solidified block must already exist on the chain, there is no need to request them again. So this function is to make the nodes discard the block list whose block height is lower than that of the solidified block when they receive it. That's roughly the logic, it's very simple. 72 | 73 | In addition, the event service function has been greatly adjusted. The background is that in the current version of the event service, the execution logic and the block execution logic are completely coupled in the code. This will lead to the situation that the exception of the event service may affect the normal block execution. This modification mainly decouples the logic of block execution and event service. In addition, a feature is added which is to support synchronizing historical data starting from a specified block height. 74 | 75 | There is one thing to note. When migrating to the new version of the event service, if users have subscribed to the fields of internal transactions, it is recommended not to migrate to the new version for now; for users who want to migrate to the new version, it is recommended to use the latest plugin version. 76 | 77 | * Boson 78 | 79 | If users use the new version, do we need to prompt them that they must use the new plugin? 80 | 81 | * Lucas 82 | 83 | Yes. 84 | 85 | * Boson 86 | 87 | Is this part of the content mentioned in the technical interpretation of Kant? 88 | 89 | * Lucas 90 | 91 | Yes, and a special document will be provided later. 92 | 93 | * Jake 94 | 95 | OK, if there is no problem, let's continue. Now, Allen, please share your part. 96 | 97 | **Enhanced Transaction Validity Verification** 98 | 99 | * Allen 100 | 101 | Regarding Pull 6181, it is related to issue 6178. It mainly describes a bug. The bug is that when processing transaction messages in p2p, an exception of numeric out-of-bounds occurs. The reason is as follows. When processing transaction messages, since the transaction type needs to be obtained, p2p will distinguish between system transactions and contract transactions and make different processing and scheduling for them. When judging the transaction type, the transaction type needs to be obtained from the contract. When the received transaction message does not carry the contract, an array out-of-bounds exception occurs at this time. So TIP-6181 fixes this problem. The method of fixing it is that when processing the transaction, before obtaining the transaction type, first determine whether the transaction carries the contract. If it does not carry it, the transaction will be directly discarded. 102 | The specific code adjustments have been shared before. Do you have any questions? 103 | 104 | * Jake 105 | 106 | If there is no questions upon this topic, then Boson, please update us on the situation of the algorithm library migration. 107 | 108 | **TIP-697: Cross-Platform Consistent java.strictMath Replacement for java.math** 109 | 110 | * Boson 111 | 112 | TIP-697 refers to the migration of our database algorithm from math to strict.math. This TIP is already in the 'final' state. The conversion is divided into two stages. One stage is to migrate the power floating-point operation from math to strictMath, which has been released in 4.7.7, and the proposal has also taken effect. The modification to be made in the 4.8.0 version is to disable the math library in Java-tron. That is to say, after this TIP takes effect, the subsequent development of Java-tron will no longer use the math library and will fully switch to strict.math. This is implemented for the subsequent compatibility with architectures such as ARM and other architectures. Do you have any questions? 113 | 114 | 115 | * Jake 116 | 117 | Will there be any further work on the algorithm library in future versions? 118 | 119 | 120 | * Boson 121 | 122 | There will be no more in the future. That is, after 4.8.0, developers should pay attention that they should not use the math library during development, and can only use strict.math. This is to ensure the consistency of numerical calculations across platforms, and it is also a prerequisite for our subsequent support of the ARM architecture. These are the two progressions. At the beginning, it was said that this migration would not be promoted in the form of a proposal, but after subsequent discussions, these migrations in 4.8.0 will still use the proposal, which is the only difference from the previous discussion. 123 | 124 | 125 | * Raymond 126 | 127 | Then what if the math library is used in a third-party library? 128 | 129 | * Boson 130 | 131 | There is only one situation of inconsistency, which is the Bancor transaction. If a third party also uses it, the relevant developers will be required to simulate a set of algorithms by themselves for adaptation. The math libraries of other languages, such as Python and Go, have strict cross-platform consistency in math calculations. If it is other languages, there is no need to consider this. Only JDK8 will have this problem, and it must be on the x86 platform and involve floating-point operations to have this inconsistent problem. If this is the case, developers need to simulate the algorithm by themselves to adapt to Java-tron. 132 | 133 | * Raymond 134 | 135 | I see. 136 | 137 | * Jake 138 | 139 | OK, then Wayne, please introduce the updated situation of the JSON-RPC interfaces in 4.8.0. 140 | 141 | **Enhanced Compatibility for Ethereum JSON-RPC Interface** 142 | 143 | * Wayne 144 | 145 | OK, I'll briefly talk about it. There are two changes to the JSON-RPC interface. The first one is that a new finalized is added to the block parameter. We should have briefly mentioned it before, and there has been no update recently. And more importantly, when printing logs and querying, two new parameters are added, namely SubTopics and BlockRange. It adds a restriction to be consistent with Ethereum. The BlockRange is currently set to 5000 by default, and the SubTopics is currently set to 2000 by default. 146 | 147 | When constructing the log filter parameters, the system will determine whether the sub topic is greater than the maximum value, and this value must be greater than 0 to take effect. If it is less than or equal to 0, there is no restriction. In addition, for the block range, it will also determine whether the query parameter will exceed the maximum value. Both are for making restrictions and verifications. 148 | 149 | Do you have any other questions? 150 | 151 | * Jake 152 | 153 | If there are no other questions, that's all for today. GreatVoyage-v4.8.0 (Kant) will be released according to the latest adjustments synchronized by everyone today. Developers who need to know about it can pay attention to the update of the technical interpretation of the version and the developer documents of specific functions. 154 | 155 | 156 | That's all for today. Thank you all for your time. Goodbye! 157 | 158 | 159 | 160 | ### Attendance 161 | * Boson 162 | * Aaron 163 | * Wayne 164 | * Brown 165 | * Blade 166 | * Gordan 167 | * Leem 168 | * Mia 169 | * Sunny 170 | * Raymond 171 | * Sunnybella 172 | * Elvis 173 | * Benson 174 | * Daniel 175 | * Lucas 176 | * Federico 177 | * Murphy 178 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 36.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 36 2 | ### Meeting Date/Time: April 24th, 2025, 6:00-6:30 UTC 3 | ### Meeting Duration: 30 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/122) 5 | ### Agenda 6 | * The GreatVoyage-v4.8.0(Kant) release and mainnet upgrade process 7 | * Hard fork proposals plan 8 | 9 | ## Details 10 | 11 | * Jake 12 | 13 | Hello everyone, welcome to Core Devs Community Call 36. Today’s agenda focuses on discussing the release of 4.8.0, the procedural work for the mainnet upgrade, and finalizing the launch timelines and order for three newly introduced proposals. 14 | 15 | Let’s dive in. Raymond, could you start by sharing the preparation status for the 4.8.0 release? 16 | 17 | * Raymond 18 | 19 | The next version is 4.8.0. All related features have been fully developed and merged into the master branch. Key features include functionality related to the Ethereum Cancun upgrade, a new version of the event service, and several other enhancements. The testnet went live on March 17, and three associated proposals have already been activated. Mainnet gray testing began on March 26, and the TIPs related to 4.8.0 have all been merged into the master branch with their statuses marked as "final." That’s the current update. 20 | 21 | * Murphy 22 | 23 | So, can we confirm a specific release date for 4.8.0 now? 24 | 25 | * Raymond 26 | 27 | The tentative date is next Tuesday, April 29. 28 | 29 | * Murphy 30 | 31 | Any issues with April 29 as the release date? 32 | 33 | * Jake 34 | 35 | If we stick to this date, this will be the last collective meeting to discuss the release before launch. 36 | 37 | Assuming no objections, Murphy, please proceed. 38 | 39 | * Murphy 40 | 41 | Alright, I’ll share my screen. 42 | 43 | Following Raymond’s update on the 4.8.0 development readiness, since we’ve tentatively set the release date as April 29, the community team will now outline the process for driving the mainnet upgrade. 44 | 45 | The estimated total duration for the mainnet upgrade is approximately 30 days, from April 29, 2025, to May 31, 2025. Here are the key steps: 46 | 47 | * Within 1–2 days after the version is released on GitHub (approximately May 1–2), the community team will notify community channels (Telegram, Discord, etc.), Super Representatives (SRs), and key project partners like exchanges and wallets to initiate upgrades. 48 | 49 | * Weekly follow-ups will be conducted with these key partners to track their upgrade progress, maintain records, and ensure cooperation, aiming for full completion by May 31. 50 | 51 | * At developer meetings near the deadline, the community team will share upgrade progress. If any critical partners haven’t upgraded for any reason, we’ll provide timely feedback. 52 | 53 | That’s the plan for the mainnet upgrade. Any questions? If not, let’s move on. 54 | 55 | * Murphy 56 | 57 | Next, Raymond will introduce the three new proposals, and we’ll discuss their launch timelines, order, and how the community should coordinate. 58 | 59 | * Raymond 60 | 61 | Version 4.8.0 introduces three proposals. Two are related to the Virtual Machine: One controls the activation of instructions for transient storage and memory copy; and the other controls two blob-related instructions. The third proposal pertains to consensus validation, which will be activated at network-layer. 62 | 63 | * Jake 64 | 65 | Is there a specific order required for launching these proposals? 66 | 67 | * Raymond 68 | 69 | They are entirely independent and have no interdependencies. 70 | 71 | * Murphy 72 | 73 | So we can initiate discussions for all three proposals simultaneously, then determine the voting dates for each based on the discussion progress. Is that acceptable? 74 | 75 | * Raymond 76 | 77 | Yes, that works. 78 | 79 | * Murphy 80 | 81 | I have a question about TIP-697, which switches all arithmetic libraries to `strict.Math`. I recall that in the previous version, this was activated via a hard fork, providing backward compatibility. Since this switch is forward-compatible, we don’t need a new proposal for it, right? 82 | 83 | * Boson 84 | 85 | This is bundled with #87. 86 | 87 | * Murphy 88 | 89 | Alright, moving on if there are no issues here. Finally, let’s sync on the upcoming proposal launch process. 90 | 91 | First, we need to confirm whether these three proposals require adaptation work from external projects. For example, when the dynamic energy model was activated, wallets with too low feeLimit settings caused transaction failures, requiring advance notice for adaptation. Developers should assess whether these proposals will impact project partners. If so, we need at least 30 days to notify them for adaptation. Please reach out to us promptly if adaptation is needed. 92 | 93 | Second, regarding the voting timeline: 94 | 95 | * If the mainnet upgrade progresses smoothly and completes by May 31, we’ll schedule developers to publish the proposals on GitHub between June 1–5, 2025 (including draft reviews and validation). 96 | 97 | * From June 7–28, 2025 (2–3 weeks), we’ll invite community developers and project partners to participate in discussions. During this period, we’ll update progress at a developer meeting between June 14–21 and collectively determine the exact voting start dates based on discussion outcomes. 98 | 99 | That’s the overview. Any questions? 100 | 101 | * Jake 102 | 103 | Murphy’s timeline is based on the April 29 release. If the release is delayed or rescheduled, all subsequent milestones will shift accordingly. Please raise any concerns or changes to the release status now. 104 | 105 | * Murphy 106 | 107 | No issues? We’ll proceed then—feel free to contact us later with questions. 108 | 109 | * Jake 110 | 111 | Great. I’ll finalize the meeting minutes shortly. For further discussions, let’s use GitHub. 112 | 113 | Thanks everyone for joining. 114 | 115 | * Murphy 116 | 117 | Thanks for attending, goodbye! 118 | 119 | ### Attendance 120 | * Boson 121 | * Aaron 122 | * Wayne 123 | * Blade 124 | * Allen 125 | * Gordan 126 | * Leem 127 | * Mia 128 | * Sunny 129 | * Raymond 130 | * Sunny Sun 131 | * Elvis 132 | * Daniel 133 | * Lucas 134 | * Federico 135 | * Murphy 136 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 38.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 38 2 | ### Meeting Date/Time: May 28th, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/136) 5 | ### Agenda 6 | * Progress of the GreatVoyage-v4.8.0(Kant) Mainnet Upgrade 7 | * Progress of [Proposal: Enable TVM Cancun instructions and Enhance Consensus Layer Verification](https://github.com/tronprotocol/tips/issues/763) 8 | * Progress of [Proposal: Reduce TRX block rewards](https://github.com/tronprotocol/tips/issues/738) 9 | * [Expand ARM Architecture Compatibility: Principle of X87 Instruction Simulation](https://github.com/tronprotocol/java-tron/issues/5954#issuecomment-2862215231) 10 | 11 | ## Details 12 | 13 | **Progress of GreatVoyage-v4.8.0 Mainnet Upgrade** 14 | 15 | * Jake 16 | 17 | Hello everyone! Let’s proceed according to today’s agenda. First, I’ll report on the current status of the v4.8.0 provincial-level rollout. Out of 27 SRs in the entire community, 19 have completed the upgrade. This week, we’ll remind SRs again to finish the upgrade before the deadline to avoid forking issues. 18 | 19 | Next, let’s talk about the launch status of the three proposals brought by v4.8.0. Will you be leading this part, Murphy? 20 | 21 | **Enable TVM Cancun instructions and Enhance Consensus Layer Verification** 22 | 23 | * Murphy 24 | 25 | Alright, I’ll take it from here. Let me share my screen first. All pre-release work has been fully completed. We’re also following up on the upgrade progress of each SR and major projects and parties, such as wallets and exchanges, according to the timeline. I just updated everyone on the SR upgrade progress—so far, everything is proceeding on schedule. 26 | 27 | Now, I’d like to introduce the three proposals in the v4.8.0 version. According to the plan, discussions on these proposals are scheduled to begin in early June. Lucas has already released the relevant proposals. Based on the resolution of the last developers’ meeting, we’ve merged these three proposals for handling. Some discussions have already started, and they’ve been deployed and run on the testnet. After a week of observation, no obvious issues have been found. Therefore, this week we plan to start promoting them to the community and invite community developers to participate in the discussions. Core devs present here, if you have any comments or questions about these proposals, please feel free to raise them. 28 | 29 | Does anyone have other questions about the progress of the three v4.8.0 proposals? If not, the discussion and launch of the proposals will proceed as planned. We’ll continue to follow up on related work according to the timeline in the future. 30 | 31 | Additionally, we need to confirm the specific launch time for the proposals. Currently, two proposals are scheduled to launch in June: one is the v4.8.0-related proposal mentioned earlier, and the other is the TRX reduction proposal. Since the TRX reduction proposal had been discussed for a period, it is planned to launch it first, around June 10th. After it takes effect, we’ll then launch the v4.8.0-related proposal about a week later. If you have different suggestions for this timeline, please speak up. 32 | 33 | * Jake 34 | 35 | Any questions about the launch time and approach? If not, we’ll follow Murphy’s proposed timeline. 36 | 37 | **Progress of Reduce TRX block rewards** 38 | 39 | * Murphy 40 | 41 | Great, if there are no other issues, we’ll proceed with this plan. Now let’s move to the third agenda item: the progress of the TRX reduction proposal. 42 | 43 | At the last developers’ meeting, we discussed this proposal, and most developers were supportive. I’ve counted the comments under the proposal and found that over 70% of the feedback supports launching it. Therefore, next, we need to focus on discussing the specific parameters for launching the proposal. The latest comments list several optional parameter schemes, including a new set used when launching the proposal on the Nile testnet: block reward is 8 TRX, vote reward is reduced to 128 TRX, totaling 136 TRX. 44 | 45 | We welcome everyone to share their opinions on the final parameter settings. If we can’t conclude today, please leave your feedback in the relevant issue after the meeting. If there are no objections, we tentatively suggest adopting the parameters from the Nile testnet first. That’s all for the update on the TRX reduction proposal. 46 | 47 | * Jake 48 | 49 | Any questions about the TRX reduction? If not, Boson will update us on the ARM architecture adaptation progress. 50 | 51 | **Progress of Expand ARM Architecture Compatibility** 52 | 53 | * Boson 54 | 55 | Can you see the screen? The current progress with the ARM architecture is that simulating x86 instructions on ARM is still not feasible, so we can only use hardcoding. Does anyone have any suggestions regarding the instruction simulation vs. the hardcoding approach? Another point is that currently, there’s a lot of self-developed work on ARM architecture performance. Companies like Google, Amazon, and Huawei all have their own ARM servers, which may have different performance characteristics. Right now, we plan to start with stress testing based on Amazon’s servers. The characteristic of the ARM architecture is that it may offer higher cost-effectiveness, but we can’t guarantee its performance will be better than x86. It just means that under the same operational costs, ARM may be more cost-effective, but we can’t fully ensure its performance is superior to x86. Based on historical data, does anyone have questions about using hardcoding on ARM? 56 | 57 | * Sunny 58 | 59 | What’s the performance gap? Are there specific data? 60 | 61 | * Boson 62 | 63 | We’re still doing stress testing, so there’s no data yet. Also, because the hardware performance of ARM servers built by different cloud service providers varies, this is a huge workload. For the global developer community and the TRON ecosystem, we’ll first choose the mainstream server configuration on AWS for testing, and we’ll obtain benchmark data. For TRON’s mainnet block synchronization needs, we can confirm that the overall performance of the ARM architecture won’t be worse than x86. 64 | 65 | * Neo 66 | 67 | Regarding follow-up work, there are two directions worth exploring, first, should we conduct opcode performance comparison research? This could be done in two forms, one is fine-grained analysis, comparing each Opcode one by one; the other is a macro-level comparison of the overall block packaging speed on the chain. However, the feasibility of these two schemes needs further discussion and confirmation. 68 | 69 | The second is related to stress testing. If we plan to carry out stress testing in the future, we need to clarify the specific test plan. It’s recommended to publish the detailed plan in an issue so that other community developers can refer to it and participate in auxiliary testing to jointly advance the research. 70 | 71 | * Boson 72 | 73 | Yes, the current stress test scores have been obtained. We’re currently conducting stress testing based on AWS. As mentioned before, many platforms support the ARM architecture, but their performance varies. Therefore, the results from ARM-based stress testing may not apply to other platforms, such as x86-based AMD and Intel platforms, which themselves have different performance characteristics. 74 | 75 | Additionally, even on the same platform like AWS, there are low, medium, and high configuration specifications, each with different performance levels, and the same applies to x86 platforms. Considering practical feasibility, we can’t stress test all configurations—we can only select commonly used configurations as test subjects. For example, we can carry out stress testing based on the recommended configurations in the README document (such as specific core counts and 32GB memory). This ensures that the test results are widely applicable and valuable as references while avoiding unnecessary resource waste and repetitive work. 76 | 77 | * Neo 78 | 79 | Regarding the hardcoding issue, how many transactions are involved if syncing from scratch? 80 | 81 | * Boson 82 | 83 | There are 48 transactions. But this is only for the mainnet—private chains can’t be counted. So even if we don’t use hardcoding now, private chains can’t handle this. If a private chain syncs from scratch and ARM doesn’t support it, especially if there are a large number of Bancor transactions, we don’t need hardcoding on the Nile testnet. The current hardcoding is all for historical data synchronization because after the proposals for 4.8.0 are launched, there won’t be data inconsistency issues on ARM. The worst case is that private chains won’t support historical synchronization. 84 | 85 | * Brown 86 | 87 | I have a question about power calculation above, the upper part. I see values for a and c recorded, but not for b. Why? 88 | 89 | * Boson 90 | 91 | Because at the 2000th power calculation, there was no inconsistency in the results. The current inconsistencies are all from square root calculations. At the 2000th power, even if the last digit differed, the final data would be consistent because TRON truncates to a `long` type. However, for 0.0005, which involves intermediate calculations, first taking the 2000th root, then squaring 2000 times, this can cause database inconsistencies. Therefore, we don’t need to handle the 2000th power case. 92 | 93 | * Neo 94 | 95 | Is there any response from the officials? 96 | 97 | * Jake 98 | 99 | No official response yet. We’ve posted in the community forums for Oracle, ARM, and Intel, and only the ARM community replied, suggesting a step-by-step calculation and hardcoding approach, which isn’t helpful for us. It seems there are no better alternatives. 100 | 101 | * Boson 102 | 103 | Since hardcoding writes the values directly without calculation, there’s no performance loss at all—it doesn’t even perform calculations. For bancor transactions, they’re almost non-existent now. 104 | 105 | If anyone is interested in ARM, you can check out this PR, which has been submitted. It mainly includes two adaptations: one is upgrading to JDK 17, which involves some coding changes; the other is supporting the ARM platform, such as JNI changes and strict.Math adjustments—these are the three main types of changes. 106 | 107 | * Neo 108 | 109 | Another question, if we support ARM in the future, will we release two versions? 110 | 111 | * Boson 112 | 113 | Yes, JDK 8 and JDK 17 will coexist long-term. One version will be for the x86 platform with JDK 8, and the other for the ARM platform with JDK 17. Unless one day we abandon JDK 8 and the syntax changes, we’ll keep both. Currently, the release notes state support for JDK 8 and above. If everything is verified to be problem-free, after a few more versions, we may eventually only support JDK 17 and above. 114 | 115 | * Neo 116 | 117 | I just thought of another question, when both are on x86, have we compared the performance of JDK 8 and JDK 17? 118 | 119 | * Boson 120 | 121 | Not yet, because Bancor transactions can’t be upgraded to JDK 17 on x86, so we can’t meet the conditions. However, after completing the ARM stress testing, we might look into JDK 17 on x86. With different versions and databases on the two platforms, there are too many variables to easily observe results. 122 | 123 | * Neo 124 | 125 | Understood. 126 | 127 | * Jake 128 | 129 | If there are no other questions, we’ll adjourn here. Thank you, everyone. Goodbye! 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | ### Attendance 138 | * Boson 139 | * Daniel 140 | * Lucas 141 | * Allen 142 | * Gordan 143 | * Sunny 144 | * Neo 145 | * Blade 146 | * Raymond 147 | * Sunny Bella 148 | * Leem 149 | * Brown 150 | * Mia 151 | * Wayne 152 | * Federico 153 | * Murphy 154 | * Jake 155 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 39.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 39 2 | ### Meeting Date/Time: June 6th, 2025, 6:00-6:30 UTC 3 | ### Meeting Duration: 30 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/140) 5 | ### Agenda 6 | 7 | * Progress of [Proposal: Reduce TRX block rewards](https://github.com/tronprotocol/tips/issues/738) 8 | 9 | 10 | ## Details 11 | 12 | **Progress of Proposal: Reduce TRX block rewards** 13 | 14 | * Jake 15 | 16 | Let's start now without waiting any longer to save everyone's time. We only have one agenda today: discussing the TRX production reduction proposal. Murphy will share the latest updates, and we'll dive straight in. 17 | 18 | * Murphy 19 | 20 | Can everyone see the screen? 21 | 22 | 23 | Alright, I’ll sync you with the latest developments and analyze the TRX production reduction plan. We’ll look at how the inflation rate is expected to change and update you on the proposal details. First, the proposal was released on March 19th, and we’ve invited community discussion for over two months. After receiving mostly positive feedback, we first discussed the proposal at the 37th developers’ meeting, where there were both supportive and opposing voices. We summarized the results and communicated them to the community through marketing and operations. Later, we launched the plan on the testnet and promoted the production reduction proposal, which didn’t cause significant community resistance. 24 | 25 | At last week’s developers’ meeting, we further confirmed the specific reduction parameters: the block reward will decrease from 16 TRX to 8 TRX, and the voting reward from 160 TRX to 128 TRX, with a total reduction ratio of approximately 77%. Today’s meeting focuses on sharing the analysis and impacts of the reduction. 26 | 27 | The proposal compares on-chain data from when it was initiated and predicts outcomes for 20%, 30%, and 50% production reductions. According to the analysis, the annual inflation rate after a 50% reduction would be -1.78% (a deflation rate of 1.78%), all within the range of -2%, which is a healthy metric compared to other mainstream public chains, indicating all options are viable. 28 | 29 | The main argument from opponents is that reducing rewards will affect stakers’ returns. We analyzed the specific impacts on stakers’ returns at different reduction ratios. Due to TRON’s unique energy model, we compared two dimensions: without energy leasing income, the annual staking yield of TRON would decrease from a maximum of 4.15%, dropping to approximately half (2.08%) at a 50% reduction. However, considering the active energy leasing market, where staked energy can be fully utilized in the energy market, the current comprehensive annual yield with leasing is as high as 9.15%. Even after a 50% reduction, the comprehensive annual yield would remain at 7.08%, still competitive compared to staking projects on other chains. This is the impact on staking returns. 30 | 31 | Regarding the impact on long-term staking rates, since there’s no direct formulaic relationship between production reduction and staking rates, we can only analyze qualitatively. Short-term after the proposal takes effect, some profit-driven funds may withdraw due to reduced returns. However, as analyzed, TRON’s staking returns remain competitive, so the withdrawal is expected to be limited. In the medium to long term, sustained deflation will increase TRX’s scarcity and value, creating a potential expectation of price appreciation. With a reduced TRX supply, the cost of obtaining energy (with a fixed energy supply) may rise, making energy more valuable. To compete for energy for transactions, more users may be incentivized to stake TRX for resources, which will impact staking rates. 32 | 33 | For the impact on burning, also a qualitative analysis: ignoring uncontrollable price factors, TRX production reduction doesn’t directly affect transaction fees. Short-term, with some stakers withdrawing, lower energy acquisition costs may lead to more transactions via staking, potentially reducing burning volume. In the medium to long term, rising transaction fees (due to potential price increases) may decrease transaction volume, also reducing burning volume. Thus, this proposal aims to adapt to TRON’s current transaction scale and activity, while the core for long-term benefits still requires finding new burning growth points and stimulating transaction scale and activity. 34 | 35 | Below is a comparison with historical token economic model changes on other public chains: 36 | 37 | BTC’s reward adjustment is pre-fixed, halving every 4 years, which has driven price increases after multiple halvings. And for ETH, it initially had a high inflation rate, about 90%; after EIP-1234 and EIP-1559 launched in 2021, it reduced rewards significantly, and post-Merge, with Layer 2 integration, ETH’s supply rate dropped from about 4.5% to 0.4%. Our reduction is more moderate by comparison. Solana on the other hand, uses a preset rule with a current 5% inflation rate and a 15% annual reduction. TRON last adjusted its supply in 2021, and after five years of ecosystem maturity and changing on-chain data, adjusting TRX rewards is now reasonable. 38 | 39 | Let’s talk about the proposal’s launch. After last week’s meeting, the parameters are confirmed as 8 (block reward) and 128 (voting reward). The proposal will launch on June 10th, 2025 (next Tuesday), and today’s meeting may be the final developers’ meeting on this proposal. The proposal is still open for feedback—please share any questions or comments via comments. Based on current on-chain data, the annual inflation rate is -0.85%, which will drop to -1.29% after the proposal takes effect, returning to the 2021-2022 level (before the energy unit price increased from 210 SUN to 420 SUN and the dynamic energy model was activated). That’s all for now. Any questions? 40 | 41 | We’ve updated the proposal with these parameters, the launch time, and relevant data. Feel free to review the proposal for details. 42 | 43 | * Neo 44 | 45 | Could you explain how the annual yields with and without energy leasing were calculated in that table? The percentages specifically. 46 | 47 | * Murphy 48 | 49 | One second, let me find that sheet for you. For the annual yield without energy leasing, we calculated it based on data: 176 TRX block rewards per block multiplied by one year, divided by the current total staked amount, resulting in a yield of 4.15% per TRX staked. The JustLend platform’s data includes energy leasing income; my calculations via other methods had slight deviations, but still around 9%. Therefore, for the "without leasing" yield, we subtracted the 5% annual energy leasing income from the comprehensive yield. 50 | 51 | * Neo 52 | 53 | Got it. Have any SRs participated in the discussion? 54 | 55 | * Murphy 56 | 57 | In the comments section, I believe no SRs have joined the discussion yet. The big whales from the community have been paying much attention to the issue, and some SRs have asked about it but do not have any feedback yet, and I haven’t seen direct SR participation in the GitHub issue. 58 | 59 | * Neo 60 | 61 | Understood. 62 | 63 | * Jake 64 | 65 | If there are no further questions, that is a wrap for today. Goodbye! 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | ### Attendance 74 | * Daniel 75 | * Gordan 76 | * Sunny 77 | * Neo 78 | * Blade 79 | * Leem 80 | * Brown 81 | * Mia 82 | * Wayne 83 | * Federico 84 | * Murphy 85 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting Template.md: -------------------------------------------------------------------------------- 1 | # All Core Devs Meeting # 2 | 3 | ### Meeting Date/Time: Thursday xx/xx/17 at 14:00 UTC 4 | 5 | ### Meeting Duration 2 hours 6 | 7 | ### [Audio/Video of the meeting]() 8 | 9 | ### [Reddit thread]() 10 | 11 | # Agenda 12 | 13 | 14 | # Decisions 15 | 16 | 17 | # Notes 18 | 19 | 20 | ## Attendance 21 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/README.md: -------------------------------------------------------------------------------- 1 | ## TRON Core Devs Meetings 2 | 3 | ### Purpose 4 | The TRON core devs meeting is a technical meeting intended to bring together all the TRON developers who play major roles in determining the direction of the TRON protocol. TRON developers provide updates to their projects, discuss various [TIPs](https://github.com/tronprotocol/tips) to improve the protocol, and support each other. 5 | 6 | ### [Previous Meetings](https://github.com/tronprotocol/pm?tab=readme-ov-file#previous-meetings) 7 | 8 | ### Who Can Attend 9 | These meetings are held by TRON core devs. The following groups are invited to attend the meetings: 10 | 11 | - TRON core developers 12 | - client developers 13 | - core TRON researchers 14 | 15 | Sometimes, a non-core java-tron developer with particular expertise on a topic is invited on to discuss a specific agenda item. If you feel you would contribute to the meetings please contact coredevs@tron.network. 16 | 17 | ### Agenda Items 18 | Agendas are posted to https://github.com/tronprotocol/pm/issues. Anyone is welcome to add an item to the agenda as long as it follows these guidelines: 19 | 20 | - The topic is technical in nature 21 | - The topic involves the TRON protocol 22 | 23 | Please note: 24 | 25 | - Dapps are generally not allowed as topics 26 | - The topic should not be philosophical 27 | 28 | The core devs meetings are not meant to decide philosophical contentious issues that should be decided by the community. 29 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Wallet Devs Meeting 01.md: -------------------------------------------------------------------------------- 1 | # Wallet Devs Community Call 2 | ## Meeting Date/Time: Wednesday, 19 Jul. 2023, 9:00 UTC 3 | ## Duration: 1 hour 4 | ## [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/60) 5 | 6 | ## Agenda 7 | * TRON WalletConnect protocol 8 | * TronWeb Updates 9 | 10 | ## Details 11 | 12 | * Jake 13 | 14 | Okay guys, let's start now and stop waiting for other attendees. Thank you all for coming. And today's topic is about two things. The first one is the TROn WalletConnect protocol and the other one is TronWeb updates. 15 | 16 | **WalletConnect Intro** 17 | 18 | * Jake 19 | 20 | Let's just go through the first topic. I guess everyone's familiar with it, so I will give a simple introduction to this. 21 | 22 | WalletConnect is a set of open-source code supported by the foundation of the same name, and it is open-source and free to integrate. Many digital wallet developers focus on the development and optimization of mobile apps, in which many of them have no PC clients but mobile apps. Correspondingly, however, a considerable number of DApps tend to be developed based on web pages and do not support or only support login by specific mobile wallet apps. So users can only use browser plug-in wallets like Metamask to connect the DApps. The process of entering the key into the plug-in wallet will also increase security risks. The introduction of WalletConnect can change this situation. 23 | 24 | In terms of function implementation, when users log in to PC-side DApps with wallet APPs that support WalletConnect, they only need to scan the QR code, like we have here on the right side, to connect web DApps with mobile wallet APPs and use the address or account information used by mobile APPs to log in to DApps and perform related tasks. Kind of easy to operate. 25 | 26 | In terms of security, WalletConnect adopts a mature authorization scheme. During this process, the private key will not leave the mobile phone, and users no longer need to use a browser extension plug-in wallet like Metamask to authorize behaviors and transactions. The mobile APP can be completed by scanning the code. Interact with PC-side DApps without worrying about asset security. 27 | 28 | * Jake 29 | 30 | That's basic what WalletConnect is providing. 31 | 32 | According to their official website, there are currently over 300 wallets supporting their ecosystem and about a total of over 3000 apps supporting them as well, including many popular defi apps such as Compound, Makers, Uniswap, and so on. 33 | 34 | **TRON WalletConnect Protocol** 35 | 36 | * Jake 37 | 38 | To use the TRON WalletConnect protocol, there are two prerequisites for it. First, wallets need to support TRON protocol of course, and second, you need to integrate with WalletConnect. 39 | 40 | * Jake 41 | 42 | So to integrate with WalletConnect, here we have [an official example](https://github.com/WalletConnect/web-examples/tree/main/wallets/react-wallet-v2) on their page, which will be sent later along with the .ppt file. First, you need to go to cloud.walletconnect.com to obtain a project ID. And then, developers should add their project details in the WalletConnect utility files on their GitHub repositories. 43 | 44 | * Jake 45 | 46 | Next page, we will have the TRON WalletConnect protocol. One of the protocol essences is the chain ID. Both the mainnet ID and the testnet ID, it is Nile, are provided. So when developing, you need to specify the chain ID so that you can get access to the right networks. And on the second page, is about the two methods you must implement. In order to sign hexstring and even plaintext, use the method of TRON_SIGN_MESSAGE, and for signing transactions, use the method TRON_SIGN_TRANSACTIONS to invoke the function to do it. So these are the two prescriptive methods to be implemented in order to use the TRON WalletConnect protocol. 47 | 48 | * Jake 49 | 50 | And that's all for the protocols. Next, we will talk about some recent updates of TronWeb. 51 | 52 | **TronWeb Updates** 53 | 54 | * Jake 55 | 56 | The latest versions of TronWeb supporting Stake 2.0 full functions are version [5.1.1](https://tronweb.network/docu/docs/5.1.1/intro) and [5.3.0](https://tronweb.network/docu/docs/Release%20Note), and here are the two main features implemented in those two versions, [TIP-541](https://github.com/tronprotocol/tips/issues/541) and [TIP-542](https://github.com/tronprotocol/tips/issues/542). Developers may pick either one to integrate with your wallet, it depends on your preference. 57 | 58 | The difference between version 5.1.1 and version 5.3.0 is shown in this table. 5.1.1 uses Webpack 4 compared to version 5.3.0 uses Webpack 5, which is more secure and compact in size after building and packing. One more thing to know, Webpack 5 does not contain some dependencies by default, like the 'Crypto' library used by TronWeb, so in order to make it work properly, the dependencies should be installed and required manually. 59 | 60 | And then in the older version, 5.1.1, the transactions are built by the client requesting the nodes to build the transactions, and in 5.3.0, transactions are built locally. This also improves security and avoids requests being intercepted. 61 | 62 | Additionally, the ether library is also bumped to 6.6.0. The newer version brings advanced syntaxes and ES6 features. And the signing and PK generating library is also changed. Elliptic used in 5.1.1 is reported that has potential vulnerabilities. So 5.3.0 replace it with the Ethereum secp256k1 library. 63 | 64 | That's all the difference between those two versions, you need to pick the version you prefer, it's totally up to you. And either of them supports the full function of Stake 2.0, so you don't have to worry about missing any new features of TRON. 65 | 66 | **Discussion** 67 | 68 | * Jake 69 | 70 | That's all the topics discussed today. So we really like to hear if you guys have any suggestions or any comments for the whole community. 71 | 72 | * Paul 73 | 74 | Yes, sure. I've been wondering whether it's on using WalletConnect version one or version two because we've had issues before. Our wallets currently support only version one. And we had issues before with other projects that did not support WallectConnect version two. So that's just something I wanted to clarify. 75 | 76 | * Jake 77 | 78 | So your wallet already supports v1 and has some trouble with v2? 79 | 80 | * Paul 81 | 82 | To me. We always support WalletConnect version two. So yeah, I just want to confirm whether Tron supports version two. 83 | 84 | * Jake 85 | 86 | The protocol is working with v2, so you are fine and free to go. 87 | 88 | * Paul 89 | 90 | And I also wanted to ask, perhaps we don't want to have too long for today. But if we were to integrate it, would it be possible to perhaps introduce us to some DApps in your ecosystem so that we can explore some synergies between you, and perhaps incent changes in the Tron ecosystem? 91 | 92 | * Jake 93 | 94 | We don't have much right now. But later we can check on that. The wallet Bitkeep and Justlend have already supported TRON WalletConnect protocols for now. 95 | 96 | * Paul 97 | 98 | Yeah, yeah. Sure. That's something that we definitely could explore. So basically, you guys so once you want to go, like amplify your ecosystem, right? By exploring the possibilities and WalletConnect and everything, that's a very strong plan to be expanding right now, right? 99 | 100 | * Jake 101 | 102 | Yeah, check. We would like to attract other users using wallets and having assets from other chains, so they can invest their assets to DApps and protocols in TRON and yeah, expand the ecosystem. 103 | 104 | * Paul 105 | 106 | So great yeah. Sure. I will definitely pass it over to our developers like to delegate and everything so yeah, sure. 107 | 108 | * Jake 109 | 110 | Yes, any suggestions besides those two topics that we talked about here? Any improvements? 111 | 112 | * Jake 113 | 114 | Okay, that's it for today. Thank you for coming. 115 | 116 | * Paul 117 | 118 | We will continue our conversation in the chat if something comes up. So yeah. And I'm looking forward to connecting some more with you guys. It was fun, thank you for keeping us in the loop on what's happening. I really enjoyed this. This whole meeting. So yeah, see you around. Okay, let's keep in touch. 119 | 120 | * Jake 121 | 122 | We will keep you updated. Sure. Thanks for coming. 123 | 124 | 125 | 126 | 127 | ## Attendance 128 | * Jake Zhao (host) 129 | * Murphy Zhang 130 | * Token Pocket (Marcus) 131 | * Now Wallet (Paul) 132 | * BitPie Wallet (Joseph Johnson) 133 | * Huobi Wallet (Vic Cui) 134 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Wallet Devs Meeting 02.md: -------------------------------------------------------------------------------- 1 | # Wallet Devs Community Call 2 2 | ### Meeting Date/Time: May 8th, 2025, 6:00-6:30 UTC 3 | ### Meeting Duration: 30 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/129) 5 | ### Agenda 6 | * Implementation of TIP-6963 Multi Injected Provider Discovery 7 | 8 | ### Detail 9 | 10 | 11 | * Murphy 12 | 13 | Welcome everyone to today's meeting. The main topic we'll discuss is TIP-6963, which aims to resolve wallet conflicts in the TRON ecosystem. Now, let's invite Gary to share the details. 14 | 15 | * Gary 16 | 17 | Thank you. I'll start by introducing the background of TIP-6963. Currently, there are two main issues with wallets in the TRON ecosystem: wallet conflicts and new wallet onboarding. Let’s elaborate on both. 18 | 19 | First, wallet conflicts: The TIP-1193 proposal suggests that plugin wallets use the `window.tron` object as the carrier for the TRON provider. When a user’s browser has multiple plugin wallets installed, injection conflicts occur because all wallets use the same `window.tron` object, causing them to overwrite each other. This means when a user intends to use Wallet A, the system might actually invoke Wallet B, significantly affecting the user experience. 20 | 21 | Second, new wallet onboarding: Besides injecting `window.tron`, mainstream wallets also inject their own global variables to avoid overwrites—for example, TokenPocket injects `window.tokenpocket`, and Gate Wallet injects `window.gatewallet`. DApps must hardcode supported wallets into their code. If a new wallet isn’t listed in the DApp’s code, users can’t use it after installation. This not only harms the user experience in the TRON ecosystem but also hinders the growth of emerging wallets and their ability to acquire users. 22 | 23 | To address these issues, we researched solutions from mainstream blockchains. The first is Ethereum’s EIP-6963 protocol, designed to resolve multi-wallet conflicts by discovering multiple wallet providers. Instead of using global variables to store providers, it leverages browser event mechanisms for communication between DApps and wallets, exposing wallet providers to DApps. The second example is Solana, which established the Wallet Standard specification. This standard defines how wallets register themselves, expose information, and how DApps retrieve wallet data, while providing security packages for both wallets and DApps. 24 | 25 | **EIP-6963** 26 | 27 | * Gary 28 | 29 | Let’s first dive into Ethereum’s EIP-6963 protocol, which uses browser events for wallet-DApp communication. Two key events are defined: 30 | 31 | * `announceProvider`: Broadcast by wallets to register their provider information. 32 | * `requestProvider`: Initiated by DApps to actively request wallet information. 33 | 34 | Workflow of EIP-6963: 35 | 36 | On the left is the DApp, and on the right is the wallet. When the wallet loads, it first broadcasts an `announceProvider` event to notify the DApp of its provider details. Concurrently, the DApp sets up a listener to monitor `announceProvider` events upon loading. Upon receiving this event, the DApp saves the collected provider information, typically displaying it as a wallet list for users to select from. Additionally, the wallet listens for `requestProvider` events from the DApp. When the DApp triggers this event (at any time after loading) to request updated wallet information, the wallet re-broadcasts the `announceProvider` event. This bidirectional communication ensures no provider information is missed. 37 | 38 | **Wallet Standard of Solana** 39 | 40 | * Gary 41 | 42 | Next, let’s discuss Solana’s Wallet Standard, which defines how wallets register themselves, how DApps retrieve wallet information, and the interface types, including TypeScript types, that wallets must implement. The standard specifies how wallets should package their data for comprehensive discovery by DApps and provides several critical npm packages: 43 | 44 | * `wallet-standard/base`: Provides TypeScript type definitions. 45 | * `wallet`: Used by wallets to register their information. 46 | * `app`: Used by DApps to retrieve and listen for wallet information. 47 | 48 | Workflow: 49 | 50 | Wallets import the `registerWallet` method from the `wallet` package, populate their details according to the TypeScript definitions, and call `registerWallet` to register. DApps import the `getWallets` method from the app package, gaining access to `get()` to fetch all wallet info and `on()` to listen for new wallet registrations, ensuring no registrations are overlooked. 51 | 52 | **Comparison of EIP-6963 and Wallet Standard** 53 | 54 | * Gary 55 | 56 | EIP-6963 advantages: Simple architecture, transparent details, rich documentation (leveraging browser events, with clear specifications in the EIP), and compatibility with EIP-1193 (which defines the provider interface). Many wallets already implement EIP-6963. 57 | 58 | EIP-6963 disadvantages: Requires self-implementing event listening/broadcasting, lacks ready-to-use npm packages, and is limited to Ethereum’s multi-wallet conflicts (event names are EIP-specific, making it chain-incompatible). 59 | 60 | Wallet Standard advantages: Strong scalability (applicable to multiple blockchains, not just Solana) and official adapters for wallet registration and DApp integration. 61 | 62 | 63 | Wallet Standard disadvantages: Complex architecture, opaque internal logic (due to npm package reliance), steep learning curve for beginners, and outdated documentation (the standard deprecated the `window.navigator.wallets` storage method without clear documentation updates). 64 | 65 | **Why TIP-6963** 66 | 67 | * Gary 68 | 69 | For the TRON ecosystem, considering factors like ecosystem compatibility, implementation cost, and user habits, we’ve chosen a solution similar to EIP-6963. This protocol complements existing TIP-1193, both use the provider interface, allowing wallets and DApps to reuse existing provider objects, leverages browser events, requiring low entry barriers and minimal implementation costs. Since most wallets already support EIP-6963, adapting to TIP-6963 only requires modifying the prefix of `announceProvider` and `requestProvider` events. No additional npm packages or documentation are needed, avoiding new technical stacks. 70 | 71 | Detailed specifications for TIP-6963: 72 | 73 | Events: 74 | * `TIP6963:announceProvider`: Triggered by wallets to declare their provider. 75 | * `TIP6963:requestProvider`: Triggered by DApps to request wallet information. 76 | 77 | Type definitions: 78 | * `providerInfo`: Includes wallet `uuid`, `name`, `icon`, and `rdns`, which is the organization name, defined by the wallet. 79 | * `providerDetail`: Contains `providerInfo` and the existing `window.tron` provider and there is no changes needed, simply reuse the current provider. 80 | 81 | And the workflow is identical to EIP-6963, using bidirectional event communication. 82 | 83 | Code examples : 84 | 85 | * Wallet side: 86 | Create a custom event `TIP6963:announceProvider` with wallet info and provider data. Dispatch this event on page load and listen for `TIP6963:requestProvider` events. On reception, re-dispatch `announceProvider` to update DApp data. 87 | * DApp side: 88 | Listen for `announceProvider` events on load, saving `providerInfo` to a wallet list for display. Trigger `requestProvider` via `dispatchEvent` when updating wallet info is needed. 89 | 90 | That is pretty much of it. 91 | 92 | * Murphy 93 | 94 | Please feel free to share any questions or suggestions. We’ve received feedback from community wallet projects about call conflicts, which is why TRON plans to adopt EIP-6963. After Gary’s presentation, does everyone understand the proposal? 95 | 96 | * Tony 97 | 98 | I have a suggestion: TRON’s existing login libraries, like adapter-like tools, should support this new protocol as soon as possible. 99 | 100 | * Benson 101 | 102 | We’ll sync with the wallet adapter team to complete support promptly. Since this is our first meeting, if there are no objections, we’ll proceed with implementation. In the future, we’ll need your help to support this protocol in your wallets. Once supported, the wallet adapter will be updated to include your new versions, ensuring consistency. 103 | 104 | To our community wallet partners: How difficult do you think implementation will be? If we proceed, what’s your estimated timeline or schedule for completing support? 105 | 106 | * Tony 107 | 108 | TokenPocket can support this quickly, possibly in the next version. It’s not complicated, especially since we already support EVM protocols—maybe just a day’s work. 109 | 110 | * Benson 111 | 112 | Gary, do we have any additional requests for other wallet providers? Beyond supporting the protocol, are there other issues to address? 113 | 114 | * Gary 115 | 116 | Not at the moment. Will this be implemented only for plugin wallets, or also for mobile apps? 117 | 118 | * Tony 119 | 120 | It should be unified. For DApps, supporting this protocol universally makes sense; otherwise, they’d need to develop two sets of code (for plugins and mobile), which is inefficient. 121 | 122 | * Gary 123 | 124 | Understood. Regarding the final launch timeline: Let’s discuss further. If there are no other issues, we’ll finalize the proposal. 125 | 126 | * Benson 127 | 128 | Implementation relies on each wallet provider. Assuming smooth discussions, we’ll gradually recommend the protocol to all wallets. Specific timelines depend on each team, but we’ll prioritize collaborating with key projects for faster adoption. 129 | 130 | * Tony 131 | 132 | I shared a website in the chat that tracks EIP-6963 wallet support progress. It’s a great testing example and tracking platform, helping projects identify supported wallets and serving as a testing ground. 133 | 134 | * Benson 135 | 136 | Great suggestion! The TRON community can explore developing a similar demo and sync it to a GitHub issue. Today’s discussion went smoothly. The community will promote the proposal over the next few days, and if there are no objections, we’ll officially proceed with development. 137 | 138 | Wallet providers can begin implementing the TIP specifications based on your schedules. 139 | 140 | That’s all for today. We may hold 1–2 follow-up meetings. Meeting notices will be posted in the group and on GitHub, so please stay tuned. Thank you all for attending! 141 | 142 | * Murphy 143 | 144 | Thanks for your time. See you at the next meeting! 145 | 146 | 147 | ### Attendance 148 | 149 | * Gary 150 | * Murphy 151 | * Benson 152 | * Tony@TokenPocket 153 | * Jake 154 | * Bot 155 | * cell 156 | * He Xiao 157 | * Leslie 158 | * lin 159 | * marke 160 | * noname 161 | * SafePal Victor 162 | * Sam Jin 163 | * Taylor 164 | * Vic 165 | * XuNeal 166 | * xwartz 167 | * Yveline --------------------------------------------------------------------------------