├── Archive ├── LICENSE ├── TRON Core Devs Meetings ├── Meeting Template.md ├── README.md ├── Meeting 49.md ├── Meeting 36.md ├── Meeting 47.md ├── Meeting 45.md ├── Meeting 44.md ├── Meeting 41.md ├── Meeting 39.md ├── Wallet Devs Meeting 01.md ├── Meeting 51.md ├── Meeting 25.md ├── Wallet Devs Meeting 02.md ├── Meeting 23.md ├── Meeting 40.md ├── Wallet Devs Meeting 04.md ├── Meeting 24.md ├── Meeting 38.md ├── Meeting 21.md ├── Meeting 20.md └── Meeting 26.md ├── Mainnet Upgrade Archive ├── GreatVoyage-v4.7.4(Bias) │ └── mainnet.md └── GreatVoyage-v4.8.0(Kant) │ └── mainnet.md ├── Democritus └── mainnet.md └── SR Meetings ├── SR Meeting 02.md └── SR Meeting 04.md /Archive: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 49.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 49 2 | 3 | 4 | ### Meeting Date/Time: October 29th, 2025, 6:00-7:00 UTC 5 | ### Meeting Duration: 60 Mins 6 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/166) 7 | ### Agenda 8 | 9 | - [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 10 | - [TIP-6780: SELFDESTRUCT only in same transaction](https://github.com/tronprotocol/tips/issues/765) 11 | 12 | ### Detail 13 | 14 | - **Murphy** 15 | 16 | Welcome, everyone, to the 49th TRON core developers community meeting. We have two topics on the agenda today. First, I'd like to ask Neo to provide an update on the development progress for version 4.8.1. 17 | 18 | **Syncing the development progress of v4.8.1** 19 | 20 | - **Neo** 21 | 22 | Certainly. Last week, we completed the standard functional testing. We also initiated a specialized testing round for the libp2p network, which we expect to conclude this week. 23 | 24 | Additionally, during our FullNode synchronization tests, a database comparison tool helped us identify a potential resource management issue in RocksDB. While this doesn't affect nodes under normal operation, it could lead to delayed memory release and a risk of OOM (Out of Memory) under extreme conditions, such as performing extensive database scans and creating a high volume of objects in a short time. The Pull Request addressing this issue is nearly ready, and once it's merged, we will conduct a round of enhanced testing. 25 | 26 | On the documentation front, the initial version has been released and will be further improved as we move forward. We are now preparing to draft the technical deep-dive articles and will need participation from our developers to contribute details for their respective features. 27 | 28 | - **Murphy** 29 | 30 | Understood. So, is the release for v4.8.1 still expected in November? 31 | 32 | - **Neo** 33 | 34 | Yes, it should still be in November, but based on our current trajectory, it will likely be in the mid-to-late part of the month. 35 | 36 | - **Murphy** 37 | 38 | And is the limited live testing for the ARM architecture also underway? 39 | 40 | - **Neo** 41 | 42 | Yes, that testing has begun. About two weeks ago, we began a staged rollout of the FullNode synchronization on several ARM devices, running the tests at different intervals. We also have a few ARM-based FullNodes running on Mainnet. No anomalies have been found so far. 43 | 44 | - **Boson** 45 | 46 | I'd like to add that there is currently an intermittent hanging issue with the unit tests in our CI process. 47 | 48 | - **Neo** 49 | 50 | Yes, we're aware of that. In previous tests, we found the probability of it hanging was quite low, but we will be running it more frequently in the coming days to monitor its behavior. 51 | 52 | - **Murphy** 53 | 54 | Alright, let's move on to our second topic. I'd like to invite Aiden to present his analysis of the impacts of the `SELFDESTRUCT` opcode modification. 55 | 56 | **Progress Sync on `SELFDESTRUCT` Opcode Modification** 57 | 58 | - **Aiden** 59 | 60 | I'll provide an update on this task. We recently completed a full scan of all internal transactions. The dataset was massive, which is why we just wrapped it up this week. Our preliminary analysis shows that within the past year's transaction data, there is a significant pattern of "create-and-destroy," where contract creation and the `SELFDESTRUCT` call occur within the same transaction. As per our previous discussions, this execution pattern will not be affected by the new `SELFDESTRUCT` logic. 61 | 62 | Our next step is to filter out this unaffected data and then conduct a deeper analysis of how the remaining transactions utilize the `SELFDESTRUCT` opcode. This will allow us to more accurately assess the real-world impact. Therefore, this analysis is still in progress, and we have not yet reached a final conclusion. 63 | 64 | - **Patrick** 65 | 66 | Is there an update on the technical overview for this change? Is it ready to be published? 67 | 68 | - **Aiden** 69 | 70 | The final section of the technical overview is still being prepared. It will detail the specific impacts identified from this transaction data analysis, so it can only be completed after the analysis is finished. 71 | 72 | - **Murphy** 73 | 74 | Okay. Also, regarding TIP-7702, which was a major topic in our last meeting, given the lack of new developments, we will not be discussing it today. We will revisit the topic once there are clear updates to share. 75 | 76 | Does anyone have any other topics they would like to discuss? If not, our meeting will conclude here. Thank you all for attending. 77 | 78 | 79 | ### Attendance 80 | 81 | * Aiden 82 | * Patrick 83 | * Blade 84 | * Boson 85 | * Federico 86 | * Sunny 87 | * Jeremy 88 | * Gordon 89 | * Leem 90 | * Daniel 91 | * Mia 92 | * Neo 93 | * Tina 94 | * Vivian 95 | * Wayne 96 | * Erica 97 | * Murphy 98 | 99 | -------------------------------------------------------------------------------- /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 47.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 47 2 | ### Meeting Date/Time: September 24th, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/157) 5 | ### Agenda 6 | 7 | - [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 8 | - [TIP-6780: SELFDESTRUCT only in same transaction](https://github.com/tronprotocol/tips/issues/765) 9 | - [Optimizing block syncing logic](https://github.com/tronprotocol/java-tron/issues/6310) 10 | 11 | 12 | ### Detail 13 | 14 | 15 | * Murphy 16 | 17 | Alright everyone, welcome to the 47th Core Devs Community Meeting. We have three topics to discuss today. First up, let’s have Neo give us an update on the development progress for version v4.8.1. 18 | 19 | **Syncing the development progress of v4.8.1** 20 | 21 | * Neo 22 | 23 | The current version has been in testing for over a week, approaching two weeks now. Most of the issues we've found are legacy ones, with a few being introduced by new features in this release. So far, we haven’t seen any critical issues pop up, but we’ll need to continue monitoring the testing process closely. 24 | 25 | In the relevant issue on the `tronprotocol/pm` GitHub repository, we have relisted all features included in the current version. We are also compiling a list of changes that are incompatible with previous versions, and we’ll post that as a comment in that issue after confirmation. 26 | 27 | The release date is not yet confirmed and will largely depend on the testing results. The main focus of the testing is on ARM platform compatibility. The earliest estimated completion time is November. 28 | 29 | * Patrick 30 | 31 | When can we expect the initial draft of the Release Notes? 32 | 33 | * Neo 34 | 35 | We plan to complete the first draft of the Release Notes within the next two weeks to give the community a heads-up on the changes in the new version. 36 | 37 | * Murphy 38 | 39 | Alright, if there are no further questions regarding v4.8.1's progress, let's move on to our second topic. I'll hand it over to Aiden to sync up on the latest progress of `TIP-6780`, which concerns the change in the `SELFDESTRUCT` opcode's behavior. 40 | 41 | **Syncing Progress on TIP-6780 (`SELFDESTRUCT` Instruction)** 42 | 43 | * Aiden 44 | 45 | Regarding the `SELFDESTRUCT` development, there are’t any significant updates to report at this time. The feature is currently in the testing phase, and so far, no issues have been found. I will have another update on the testing progress at the next core dev meeting, and provide an assessment of the expected impact of the opcode change on on-chain contracts. 46 | 47 | 48 | * Neo 49 | 50 | Speaking of the impact assessment, I just want to confirm something on Nile testnet: I remember it being mentioned that this change would not affect historical contracts on the Nile testnet. However, Nile has already activated the relevant proposal, and this change involves a fix to the Stake 1.0 resource handling logic, which is not backward-compatible. So, I’m wondering, have we actually confirmed that this change is guaranteed not to impact existing smart contracts on Nile that might be using this logic? 51 | 52 | 53 | * Aiden 54 | 55 | We haven't compiled detailed statistics on this specific question yet. This change is indeed a fix for a previous issue. I will investigate this further and we can discuss it in detail at the next meeting. (Neo: Sounds good.) 56 | 57 | 58 | * Murphy 59 | 60 | 61 | Okay, let's move on to our third agenda item on optimizing the block syncing logic. I'd like to invite Leem to introduce the topic. 62 | 63 | 64 | **Optimizing block syncing logic** 65 | 66 | * Leem 67 | 68 | Regarding this [issue](https://github.com/tronprotocol/java-tron/issues/6310), the current fix involves adding a `volatile` modifier. But I think this solution presents a problem: it creates ambiguity about which thread triggers the next sync (`syncNext`), leading to logical uncertainty. My question is, why wasn't this part of the state validation and cleanup logic placed directly inside the `synchronized` block to make it an atomic operation? 69 | 70 | 71 | * Lucas 72 | 73 | The original design was to keep the lock granularity as minimal as possible. If we were to adopt your proposal, the entire message handler function might need to be locked. 74 | 75 | * Leem 76 | 77 | My concern is that if it's not placed within the `synchronized` block, a situation can arise where both the peer thread and the block processing thread can trigger a sync. In the issue we reproduced, the peer thread no longer met the conditions to trigger a sync, but because it read a stale state, it incorrectly triggered the next sync anyway. This creates logical confusion. 78 | 79 | * Brown 80 | 81 | We need to consider that the `syncNext` function can be time-consuming because it involves block processing. Placing it directly within the main `getBlockLock()` could impact overall performance. 82 | 83 | * Leem 84 | 85 | But if you look at the `SyncService`, the logic for processing synced blocks is itself within a `synchronized` block, and it also calls `syncNext` from within the lock when conditions are met. My suggestion is to make the logic here consistent with the pattern in `SyncService`, where the block processing thread is solely responsible for the trigger. This would ensure logical clarity and consistency. 86 | 87 | * Lucas 88 | 89 | We would need to further analyze and evaluate whether this change could introduce other scenarios, such as deadlocks. 90 | 91 | * Murphy 92 | 93 | Thank you all for the in-depth discussion. This is obviously a highly technical issue, so I suggest the developers involved do a more thorough analysis, and we will continue this discussion in a future meeting. This issue is currently closed, but it can be reopened if the analysis leads to new findings. This concludes today's meeting. Thank you all for participating. 94 | 95 | 96 | *** 97 | 98 | 99 | ### Attendance 100 | 101 | * Aiden 102 | * Patrick 103 | * Blade 104 | * Federico 105 | * Mia 106 | * Murphy 107 | * Jeremy 108 | * Jack 109 | * Boson 110 | * Brown 111 | * Tina 112 | * Vivian 113 | * Sunny 114 | * Neo 115 | * Gordon 116 | * Leem 117 | * Lucas 118 | * Erica 119 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 45.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 45 2 | ### Meeting Date/Time: August 27th, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/157) 5 | ### Agenda 6 | 7 | - [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 8 | - [Fullnode sync fails or stalls at block heights ending in 99 or 999 from official snapshot](https://github.com/tronprotocol/java-tron/issues/6425) 9 | - [Optimize RocksDB's backup function](https://github.com/tronprotocol/java-tron/issues/5698) 10 | 11 | ### Detail 12 | 13 | * Murphy 14 | 15 | Welcome, everyone, to the 45th TRON Core Devs Community Meeting. We have three main topics on the agenda today. First, I'd like to invite Brown to provide an update on the development progress for version v4.8.1. 16 | 17 | **Syncing the development progress of v4.8.1** 18 | 19 | * Brown 20 | 21 | Most of the Pull Requests (PRs) for the v4.8.1 release have now been merged into the 4.8.1 branch. The next step is to complete our internal self-testing. Once that's done, we will hand it over to the QA team for formal testing. If our self-testing proceeds smoothly, we expect to submit it for QA review next Monday, September 1st. The testing period is estimated to be between one and two months, with a projected completion by the end of September. We will confirm the exact timeline as we get closer. 22 | 23 | * Patrick 24 | 25 | This testing schedule seems longer than for previous releases. Is there anything different about the testing for this version? 26 | 27 | * Brown 28 | 29 | The main reason for the extended timeline is the significant number of changes related to ARM architecture compatibility. Some potential issues may only surface after the node has been running for an extended period, which can't always be caught by standard functional tests. 30 | 31 | * Patrick 32 | 33 | I see. I assume any changes to this projected timeline will be communicated in future meetings? (Brown: Yes, that's correct.) Also, who will be responsible for coordinating and tracking everyone's self-testing progress? 34 | 35 | * Brown 36 | 37 | I will be responsible for tracking the completion status of the self-testing. We will only formally submit the release to QA after everyone has completed their tests. The goal here is to encourage everyone to find and resolve as many of their own bugs as possible during the self-testing phase, rather than discovering them after the handover. 38 | 39 | * Murphy 40 | 41 | So, is the scope for v4.8.1 basically finalized now, with no additional new features being added? Can we begin preparing the release notes? 42 | 43 | * Brown 44 | 45 | That's correct. Regarding the release notes, it might be a bit early since there's a long gap between the start of QA testing and the final release. We will evaluate the timing. 46 | * Murphy 47 | 48 | Understood. Let's conclude this topic for now. We will continue to follow up on the progress of v4.8.1 in our upcoming meetings. Now, let's move to our second agenda item. I'd like to invite Boson to discuss the issue regarding RocksDB backups. 49 | 50 | 51 | **RocksDB Backup Issue & Configuration Cleanup** 52 | * Boson 53 | 54 | This issue is actually related to an optimization we previously disabled, which is also the third topic of the meeting: the RocksDB database backup feature. This feature is configured to perform a full backup of all databases at a fixed block interval. This backup process is synchronous and halts the processing of blocks. 55 | 56 | In the early days, TRON's data volume was not large, and a backup might be completed in one or two seconds. But now the data volume has reached 2.5T, and a single backup takes one to three minutes, which causes block synchronization to stall. 57 | 58 | This backup feature currently has two main problems: first, it is highly inefficient, severely impacting node synchronization. Second, the feature itself is unusable because new databases were added later, but the backup function was not made compatible, resulting in the backed-up data being incomplete and unusable for restoration. 59 | 60 | So, my recommendation is to directly deprecate this backup feature. 61 | 62 | * Patrick 63 | 64 | So, just to clarify, when users report that their node's sync freezes at block heights ending in, for example, 99 or 999, it's because this backup process is being triggered? But isn't this feature disabled by default? 65 | 66 | * Boson 67 | 68 | Exactly. The configuration file allows users to set a block interval for backups. If a user enables this and sets the interval to 10000, the backup will trigger at every block height ending in 9999, causing the node to hang for one to two minutes. 69 | 70 | And yes, the feature is disabled by default. However, some developers attempt to use these configuration settings, not realizing the feature is broken, which leads to confusion. For that reason, I also propose that we check the codebase for all deprecated configuration options and clean them out entirely. I plan to create two issues for this: one to remove the backup feature, and another to clean up all unused configurations and associated code. 71 | 72 | * Patrick 73 | 74 | For the users who may have already enabled this backup feature, will its removal impact them? 75 | 76 | * Boson 77 | 78 | No, there will be no negative impact. The data produced by this feature is already incomplete and unusable for restoring a node. It is, for all practical purposes, a non-functional feature. 79 | 80 | * Patrick 81 | 82 | Speaking of configuration files, the current location within the java-tron repository is not very intuitive to find. Are there any plans to make it more accessible? For instance, could we add a direct link to it in the project's main README file? 83 | 84 | * Boson 85 | 86 | That's a great point. The current documentation links to the mainnet config in the tron-deployment repository, which is planned for deprecation. We definitely need to update this. Linking directly to the configuration file within the java-tron codebase from the README is a good solution for better visibility and convenience. 87 | 88 | * Murphy 89 | 90 | Alright. Are there any other questions on this topic? If not, that concludes our meeting for today. We will follow up on the action items discussed here in our next session. Thank you, everyone. 91 | 92 | ### Attendance 93 | 94 | * Aiden 95 | * Patrick 96 | * Allen 97 | * Blade 98 | * Boson 99 | * Brown 100 | * Sunny 101 | * Federico 102 | * Gordon 103 | * Lucas 104 | * Mia 105 | * Wayne 106 | * Tina 107 | * Erica 108 | * Murphy 109 | 110 | 111 | 112 | 113 | 114 | -------------------------------------------------------------------------------- /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 November 5, 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 | ARM & JDK 17 support: 27 | 28 | [Issues 5954](https://github.com/tronprotocol/java-tron/issues/5954): Expand ARM Architecture Compatibility 29 | 30 | [Issues 5976](https://github.com/tronprotocol/java-tron/issues/5976): Upgrade to JDK 17 for ARM Architecture 31 | 32 | TIP: 33 | 34 | [TIP-6780](https://github.com/tronprotocol/tips/issues/765): SELFDESTRUCT only in same transaction 35 | 36 | [TIP-767](https://github.com/tronprotocol/tips/issues/767): Transitioning Voting Window configuration to Chain Governance 37 | 38 | API: 39 | 40 | [Issues 5910](https://github.com/tronprotocol/java-tron/issues/5910): Implement eth_getBlockReceipts method 41 | 42 | [Issues 6330](https://github.com/tronprotocol/java-tron/issues/6330): `eth_call` does not return data like the `triggerconstantcontract` interface does 43 | 44 | [Issues 6334](https://github.com/tronprotocol/java-tron/issues/6334): Optimize the configuration switch used for zkSNARK and shielded transaction 45 | 46 | [Issues 6339](https://github.com/tronprotocol/java-tron/issues/6339): Add a new API to query the real-time vote count of witness 47 | 48 | [Issues 6343](https://github.com/tronprotocol/java-tron/issues/6343): Performance Optimization for eth_getLogs/eth_getFilterLogs with Large-scale Query Parameters 49 | 50 | Database: 51 | 52 | [Issues 6335](https://github.com/tronprotocol/java-tron/issues/6335): Section-Bloom Control Optimization 53 | 54 | Doc: 55 | 56 | [Issues 6337](https://github.com/tronprotocol/java-tron/issues/6337):README badge display errors 57 | 58 | [feat(doc): update readme for telegram groups and doc link #6364](https://github.com/tronprotocol/java-tron/pull/6364) 59 | 60 | Network: 61 | 62 | [Issues 6310](https://github.com/tronprotocol/java-tron/issues/6310):gt `lastNum` error reported when synchronizing blocks 63 | 64 | [Issues 6336](https://github.com/tronprotocol/java-tron/issues/6336):The light node incorrectly reports a FORKED disconnection 65 | 66 | [Issues 5989](https://github.com/tronprotocol/java-tron/issues/5989):Ambiguous Reason Code in Disconnection Message 67 | 68 | [Issues 6279](https://github.com/tronprotocol/java-tron/issues/6279):Exception occurred when synchronizing blocks 69 | 70 | [Issues 6297](https://github.com/tronprotocol/java-tron/issues/6297):P2P message rate limit 71 | 72 | [Issues 6272](https://github.com/tronprotocol/java-tron/issues/6272):gt `highNoFork` error reported when synchronizing blocks 73 | 74 | [feat(net): optimize fetch inventory message processing logic #5895](https://github.com/tronprotocol/java-tron/pull/5895) 75 | 76 | Deployment Optimization: 77 | 78 | [Issues 6281](https://github.com/tronprotocol/java-tron/issues/6281):Invalid witness address when the localwitness is null 79 | 80 | [Issues 6299](https://github.com/tronprotocol/java-tron/issues/6299):Private node fails to start without `Blackhole` configured in `config.conf` 81 | 82 | [Issues 6218](https://github.com/tronprotocol/java-tron/issues/6218):Enrich FullNode command-line-options 83 | 84 | [feat(config): sync config.conf with tron-deployment #6332](https://github.com/tronprotocol/java-tron/pull/6332) 85 | 86 | [feat(gradle): upgrade the maven publishing #6367](https://github.com/tronprotocol/java-tron/pull/6367) 87 | 88 | [fix(pb): protocol buffer file syntax compatibility issue #6386](https://github.com/tronprotocol/java-tron/pull/6386) 89 | 90 | [fix(CheckStyle): only fix CheckStyle #6392](https://github.com/tronprotocol/java-tron/pull/6392) 91 | 92 | Security: 93 | 94 | [feat(dependencies): update dependencies for security #6400](https://github.com/tronprotocol/java-tron/pull/6400) 95 | 96 | Event Service: 97 | 98 | [Issues 6438](https://github.com/tronprotocol/java-tron/issues/6438):Optimize event service to obtain transaction information 99 | 100 | Test Case: 101 | 102 | [fix(test): release resource of testcases gracefully #6437](https://github.com/tronprotocol/java-tron/pull/6437) 103 | 104 | [fix(test): remove all junit dir and add timeout for gRPC call #6441](https://github.com/tronprotocol/java-tron/pull/6441) 105 | 106 | ## Implementation Progresss 107 | 108 | Implementation status of Included TIPs in java-tron. 109 | 110 | TIP | [TIP-6780](https://github.com/tronprotocol/tips/issues/765) | [TIP-767](https://github.com/tronprotocol/tips/issues/767) | | 111 | |----------------|-----------------------------------------------------------------------|-----------------------------------------------------------------------|--------| 112 | | **Java-tron** | [PR Submitted](https://github.com/tronprotocol/java-tron/pull/6383) | [PR Submitted](https://github.com/tronprotocol/java-tron/pull/6399) | | 113 | 114 | ### Readiness Checklist 115 | 116 | **List of outstanding items before deployment.** 117 | 118 | 119 | 120 | - Deploy Clients 121 | - [ ] Java-tron v4.8.1 122 | 123 | 124 | ## Network Status 125 | 126 | ### Network Upgrade Plan 127 | 128 | Estimated Nile upgrade time: (TBD) 129 | 130 | - [ ] Notify the community to upgrade (TBD) 131 | - [ ] Follow up to remind the community to complete the upgrade (TBD) 132 | 133 | Estimated mainnet upgrade time: (TBD) 134 | 135 | - [ ] Notify the community, SRs, CEX, Wallets, DEX, etc.to upgrade (TBD) 136 | - [ ] Follow up the upgrade status and progress closely (Contact project team every week, record the upgrade progress) 137 | - [ ] Ensure the SRs, CEX, Wallets to complete (TBD) 138 | 139 | Estimated Shasta upgrade time: (TBD) 140 | 141 | - [ ] Notify the community to upgrade (TBD) 142 | 143 | ### Proposals Plan(Fork Plan) 144 | 145 | TBD 146 | 147 | ### Network Upgrade and Fork Status 148 | 149 | | Network | Github | Kant Release Date | Latest Status | Fork | 150 | |---------|------------|-----|-----|-----| 151 | | [Nile](https://nileex.io/) | https://github.com/tron-nile-testnet/nile-testnet | | | | 152 | | [Mainnet](https://tron.network/) |https://github.com/tronprotocol/java-tron | | | | 153 | | [Shasta](https://www.trongrid.io/shasta) | https://github.com/tronprotocol/java-tron | | | | 154 | 155 | Nile Upgrade Instruction: https://nileex.io/run/getRunPage 156 | 157 | Mainnet/Shasta Upgrade Instruction： https://tronprotocol.github.io/documentation-en/releases/upgrade-instruction 158 | 159 | 160 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 44.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 44 2 | ### Meeting Date/Time: August 13th, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/156) 5 | ### Agenda 6 | 7 | - [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 8 | - [Expand ARM Architecture Compatibility java-tron](https://github.com/tronprotocol/java-tron/issues/5954) 9 | - [Optimizing cryptographic algorithm implementations](https://github.com/tronprotocol/java-tron/issues/6374) 10 | - [TIP-6780: SELFDESTRUCT only in same transaction](https://github.com/tronprotocol/tips/issues/765) 11 | 12 | ### Detail 13 | 14 | * Murphy 15 | 16 | Welcome everyone to the 44th TRON core devs community call. Today we have four topics. First, we will sync up on the development progress of 4.8.1. Second, we'll discuss the new issues found in ARM architecture compatibility. Third, we'll check the impact of optimized cryptographic algorithm. And finally, we'll go over TIP-6780. Now, let's have Neo update us on the development of 4.8.1. 17 | 18 | 19 | **Syncing the development progress of v4.8.1** 20 | 21 | * Neo 22 | 23 | Almost half of the pull requests have been merged. The remaining half is still awaiting approval for merging. Once all are merged, we will need to self-test all the pull requests using the release branch. And then, we'll invite QA team to test. 24 | 25 | Also, we might want to be on the safe side and resynchronize it. This includes resynchronizing on both x86 and ARM platforms. We'll rerun nodes to ensure that the code has no impact on existing x86 platforms and that it runs properly on the ARM platform. This is the most important aspect. 26 | 27 | * Murphy 28 | 29 | Ok, is there a rough plan for the release time? Because we would like to let the community know in advance. 30 | 31 | * Neo 32 | 33 | Well, because this ARM version includes more significant changes, we may need to conduct a relatively long grayscale phase for this specific version. Perhaps one to two months or even longer, which means that the expected release time will not be earlier than October. 34 | 35 | * Murphy 36 | 37 | Thank you Neo, does any one have more questions about the progress of v4.8.1? If not, we will move to the next topic, let's have Boson update the progress of ARM platform compatibility. 38 | 39 | 40 | **Expand ARM Architecture Compatibility** 41 | 42 | * Boson 43 | 44 | Sure. Previously, the RocksDB engine on the x86 platform could directly open a LevelDB database. To ensure compatibility, this scenario is no longer supported after this upgrade. If a LevelDB database exists in an x86 environment but the RocksDB engine is configured, an error will be reported and the system will fail to start. 45 | 46 | * Neo 47 | 48 | Agreed, to align with previous versions (previously, X86 nodes could not start on JDK 11/17), we've added a runtime check. If an X86 node is detected running a version later than JDK 8, the system will report an error and exit. This complies with official documentation that states that X86 nodes should use JDK 8. 49 | 50 | The ultimate goal is to bring RocksDB for X86 to the same version as ARM and ensure both platforms use a unified code base. This will ultimately allow both X86 and ARM to seamlessly use later JDK versions. LevelDB will still be X86-specific, but this may be unified later. 51 | 52 | * Wayne 53 | 54 | Can the ARM platform support higher JDK version than JDK 17? 55 | 56 | * Boson 57 | 58 | The ARM environment currently supports JDK 17. For ARM, running on JDK 17 or later (such as JDK 21) will not impose runtime restrictions, as later versions are expected to be backward compatible, and running on these versions helps verify compatibility. 59 | 60 | Furthermore, I suggest to simplify the `start.sh` script. The existing `start.sh` script is complex and requires JDK 17 adaptation. We have decided to retain the existing complex `start.sh` script but will not actively maintain it for now. 61 | 62 | A new, simplified script named `start.sh.simple` will be introduced. This new script will only support the start and stop commands and remove complex features. `start.sh.simple` will be clearly marked as a simple example and not suitable for production environments, which typically use customized startup scripts. This new simplified script will be compatible with both x86 and ARM platforms, and JDK 8 and JDK 17+. 63 | 64 | * Murphy 65 | 66 | Alright, if there's nothing more to discuss, let's have Federico talk about the progress of cryptographic algorithm optimization. 67 | 68 | **Optimizing cryptographic algorithm implementations** 69 | 70 | * Federico 71 | 72 | The optimization work mainly targets BN128 precompiled contracts and secp256k1 signature algorithm. Previously, I shared unit test results demonstrating that the `gnark` algorithm delivers significantly better performance. Today, I will provide updated test data reflecting the overall block production performance. 73 | 74 | The integration delivered substantial performance gains across multiple modules. For BN128 precompiled contracts, addition is ~6× faster (23 μs → 4 μs), multiplication ~47× faster (2 ms → 49.7 μs), and pairing ~97× faster (62 ms → 640 μs). 75 | 76 | In the Secp256k1 cryptographic algorithm, signature time dropped from 1.6 ms to 35 μs, and verification (ECKV2) from 1 ms to 50 μs (~18× faster) on both ARM and x86. During mainnet fast sync, block transaction signature verification latency fell from 47.3 ms to 8 ms, cutting ~39 ms per block and significantly improving sync speed, with minimal impact on block times. In the Zero-Knowledge Proof Module (ZKM) on the Nile testnet, proof verification time was reduced from ~60 ms to 6–7 ms, achieving a ~10× speedup. 77 | 78 | * NEO 79 | 80 | This performance improvement has indeed been significant, but the team needs to further discuss specific implementation strategies, particularly the impact of BLS128 optimization on consensus. They are also considering setting signature verification asynchronously or in parallel with transaction execution, which could potentially save even more time and remains to be tested. 81 | 82 | * Murphy 83 | 84 | Now, let's have Aiden go over the update of TIP-6780. 85 | 86 | **TIP-6780: SELFDESTRUCT only in same transaction** 87 | 88 | * Aiden 89 | 90 | We conducted a statistical analysis to assess the scope of the impact, including a review of current contracts and the distribution of certain assets within them. While over 5,000 contracts currently use the SELFDESTRUCT instruction, only four of these have balance more than 100,000 TRX involving it. Based on this analysis, the overall impact on existing contracts is expected to be minimal. 91 | 92 | * Murphy 93 | 94 | If there are no other questions, let's proceed as decided. Thank you all for attending today. Goodbye! 95 | 96 | 97 | 98 | ### Attendance 99 | * Daniel 100 | * Raymond 101 | * Sunny 102 | * Neo 103 | * Leem 104 | * Brown 105 | * Elvis 106 | * Gordon 107 | * Sunny Bella 108 | * Allen 109 | * Boson 110 | * Mia 111 | * Federico 112 | * Wayne 113 | * Lucas 114 | * Aiden 115 | * Tina 116 | * Darcy 117 | * Murphy 118 | -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Meeting 41.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 41 2 | ### Meeting Date/Time: July 2nd, 2025, 6:00-7:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/145) 5 | ### Agenda 6 | 7 | * [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 8 | * [HTTP calls experience delay due to rate limiting](https://github.com/tronprotocol/java-tron/issues/6363) 9 | * [Optimizing cryptographic algorithm implementations](https://github.com/tronprotocol/java-tron/issues/6374) 10 | 11 | 12 | ### Detail 13 | 14 | * Murphy 15 | 16 | Ok, let's get started. Welcome to the 41st core developers meeting. Today we have three topics: first, discussing the development progress of v4.8.1; second, discussing the issue of HTTP calls experiencing delay due to rate limiting and corresponding solution; and third, discussing the proposal of optimizing cryptographic algorithm implementations. Let's dive into the first topic directly and ask Neo to share the development progress of v4.8.1 17 | 18 | 19 | * Neo 20 | 21 | Alright. Version 4.8.1 is scheduled to be tested next week (mid-July). All PRs have been merged into the branch. There are still nine issues whose PRs have not been submitted yet. We plan to submit and review them this week. After the review is completed, they will be merged into the branch before next Friday. 22 | 23 | 24 | * Murphy 25 | 26 | When will the scope of functionality of version 4.8.1 be finally determined? 27 | 28 | 29 | * Neo 30 | 31 | Probably next week, and I will update the status under PM repository issues. 32 | 33 | 34 | * Murphy 35 | 36 | OK, good, and will there be any proposals that require a hard fork to open in version 4.8.1? 37 | 38 | 39 | * Neo 40 | 41 | There are two TIPs that may need a hard fork, it will be determined in the next meeting. 42 | 43 | 44 | * Murphy 45 | 46 | Got it, and as we mainly focus on version 4.8.1 recently, the development progress of v4.8.1 will be a permanent topic before it’s released. Any questions from other developers? If not, let’s put a pin in it, and circle back in the next meeting. Now we will move to the second topic. HTTP calls experience delay due to rate limiting from Lucas. 47 | 48 | 49 | * Lucas 50 | 51 | OK. Let me first introduce the background. Our http interface has a rate limit function, which means that the number of calls per second can be limited. Then the Google service we are using now provides two interfaces. The first one is the acquire interface, which is a blocking interface, and we are currently using this interface. In addition, it also provides a non-blocking interface. The problem with the blocking interface is that when the QPS is very high, it may take dozens of seconds to return the result. I would like to discuss whether this needs to be optimized. 52 | 53 | 54 | * Sunny 55 | 56 | Can you make it support both interfaces to let the client decide which one to choose? 57 | 58 | 59 | * Lucas 60 | 61 | It is also possible to support both interfaces, which requires adding a configuration item. However, non-blocking is generally used. Because the blocking method, first, does not give a good user experience, and second, it also affects the stability of the service. Of course, it is not ruled out that some users just want to use the blocking method and get the result after a period of time after sending the request. 62 | 63 | 64 | * Neo 65 | 66 | I have a question: what’s the method adopted by Trongrid? 67 | 68 | * Wayne 69 | 70 | Trongrid's QPS is done by itself. It has two methods. Now Nginx generally returns directly without this delay. If the limit is exceeded, the error code 503 is returned. And if the user has an API key, the return code is 403. 71 | 72 | Lucas mentioned that the way to directly try is to return directly, which can be controlled by yourself. You can set a timeout by yourself. 73 | 74 | 75 | * Lucas 76 | 77 | If we talk about the simple server design, the traditional trigger is non-blocking. Because we must first ensure the stability of the server. If it is a blocking method, then my queue in the server will become more and more, and the pressure on the server will become greater and greater. But the blocking user scenario just mentioned is not ruled out. 78 | 79 | 80 | * Wayne 81 | 82 | If it is changed to the one of try, that is to say, the one of try can actually set a timeout, right? Then the user can wait for a while, or he can set a very short timeout and return directly. Yes, it seems that both can be supported, right? 83 | 84 | If it can be supported, if we really change it to try, it means that by default we try and give it a time of, for example, 60 seconds or whatever. If the user does not set it by himself, he will still wait for 60 seconds. This may be more consistent with the current phenomenon, right? 85 | 86 | 87 | * Neo 88 | 89 | I think this proposal needs to be further discussed. I suggest not including it into version 4.8.1, we can rethink it carefully. 90 | 91 | 92 | * Lucas 93 | 94 | I agree, as the scenario is not certain, I will do more verification and welcome comment the opinions under the issue. 95 | 96 | 97 | * Murphy 98 | 99 | Alright, do you have any other questions? So we will postpone introducing this proposal, it’s to be discussed in the future. And the last topic is optimizing cryptographic algorithm implementations from Federico. 100 | 101 | 102 | * Federico 103 | 104 | This topic is mainly aimed at the current Java-tron, where zero-knowledge proof transactions are prone to timeout. I have proposed two optimization solutions for this problem. The first is to use JNI to encapsulate the ArcWorks library from zkBob to improve the efficiency of the BN128 precompiled contract, which can achieve a speed increase of 3 to 30 times. The second is to use the optimization of the gnark-crypto from Besu. 105 | 106 | Then we conducted a comprehensive test on the performance of all of his above solutions. The test results are: the arcworks optimization solution can improve the addition operation of BN128 by 2.5 times, and the multiplication operation of the BN128 prediction contract by about 26 times. Other data are listed in the issue, please take a look. 107 | 108 | 109 | 110 | * Neo 111 | 112 | It can be proved by the data that the performance can be indeed enhanced by these two methods. And as far as I know, they are all being used widely on Ethereum where there are a lot of zero-knowledge transactions. But introducing the JNI into TRON is still at risk, and I think it should be further tested. 113 | 114 | 115 | * Federico 116 | 117 | Alright, understood, I will continue to do further testing before I come up to a conclusion whether it should be migrated to TRON. And I will share the testing result in the future. 118 | 119 | * Murphy 120 | 121 | Any other topics to discuss? 122 | 123 | If not, the meeting ends here. And we will continue to discuss the progress of version 4.8.1 during the coming meetings. Thank you all for attending. Goodbye! 124 | 125 | 126 | ### Attendance 127 | 128 | * Daniel 129 | * Lucas 130 | * Gordan 131 | * Neo 132 | * Leem 133 | * Brown 134 | * Mia 135 | * Sunny Bella 136 | * Boson 137 | * Blade 138 | * Wayne 139 | * Federico 140 | * Murphy 141 | 142 | 143 | -------------------------------------------------------------------------------- /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/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/Meeting 51.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 51 2 | 3 | ### Meeting Date/Time: December 3rd, 2025, 6:00-7:00 UTC 4 | ### Meeting Duration: 60 Mins 5 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/176) 6 | ### Agenda 7 | 8 | - [Syncing the development progress of v4.8.1](https://github.com/tronprotocol/java-tron/issues/6342) 9 | - [Introducing Trident 0.11.0 features](https://github.com/tronprotocol/trident/tree/release_0.11.0) 10 | - [Introducing wallet-cli 4.9.2 features](https://github.com/tronprotocol/wallet-cli/releases/tag/wallet-cli-4.9.2) 11 | 12 | ### Detail 13 | 14 | - **Murphy** 15 | 16 | Welcome to the 51st Core Devs Community Meeting. We have three topics today: Neil will update us on the v4.8.1 development progress; Tina will introduce the new features in Trident 0.11.0; and Daniel will share the functional updates in the new Wallet-cli version. 17 | 18 | - **Neo** 19 | 20 | Currently, v4.8.1 is in the final testing phase on the Nile testnet. We expect to deploy the full release to Nile tomorrow, followed by an observation period of approximately 3 days. If all metrics are normal, we plan to release the Nile test report around the 8th and subsequently coordinate the phased rollout of Mainnet SR/BP nodes. This observation cycle will last about two weeks. 21 | 22 | If the rollout proceeds smoothly, we target **Monday, December 22nd** for the official Mainnet release. Following this, we will proceed with the second batch of Mainnet node deployments, followed by the third batch one week later. Finally, we will wait for community nodes to upgrade sequentially. The entire process is expected to take 1-2 weeks, after which the upgrade of the remaining nodes will be completed. 23 | 24 | We expect all network nodes to complete the upgrade by late January. Regarding the initiation of new governance proposals: considering the Lunar New Year holidays in February, to mitigate risk, we anticipate initiating proposals after the holidays. 25 | 26 | - **Murphy** 27 | 28 | Will proposal testing be conducted on the Nile testnet? 29 | 30 | - **Neo** 31 | 32 | Yes. If everything goes as planned, we will conduct proposal testing concurrently with the release of the test report on the 8th. 33 | 34 | - **Murphy** 35 | 36 | Understood. This involves two proposals? 37 | 38 | - **Neo** 39 | 40 | Yes. 41 | 42 | - **Murphy** 43 | 44 | One more question: Are there any changes to the v4.8.1 progress tracked in the GitHub PM repository?" 45 | 46 | - **Neo** 47 | 48 | A few new PRs were added recently. We will sync up again this week and tag you once updated. 49 | 50 | - **Murphy** 51 | 52 | Understood. Let's move to the next topic. Tina will introduce the new features in Trident 0.11.0. 53 | 54 | 55 | **Introducing Trident 0.11.0 features** 56 | 57 | - **Tina** 58 | 59 | Okay. Trident 0.11.0 includes two major functional updates. 60 | 61 | First, it adds support for the new v4.8.1 RPC interfaces, specifically adding the interface for real-time voting queries. 62 | 63 | Second, we've streamlined the development experience by providing new interfaces and utility classes. Specifically, the new `getAccountPermissions` interface allows you to query all permission data (Owner, Witness, and Active) in a single call. We also encapsulated `accountPermissionUpdate` for direct invocation when modifying multisig permissions. 64 | 65 | Additionally, we introduced a helper class, `ActivePermissionOperationsUtils`. This assists developers in quickly constructing Active permission groups. For example, if you want to assign certain permissions to a specific Active group, this utility class can generate the corresponding Permission fields and set them directly, which is very convenient. 66 | 67 | We have provided a comprehensive unit test example you can refer to for the full workflow: Query Permissions -> Construct Owner Permissions -> Modify Corresponding Permissions -> Initiate Update Transaction. 68 | 69 | I want to highlight one point: **when initiating an Active multisig transaction, you must set the Permission ID**. You need to use the `setContractPermissionId` method to specify which permission authority is being used to send the transaction. 70 | 71 | Other updates include routine bug fixes, error message optimization, Gradle and dependency upgrades, and added support for JDK 17. 72 | 73 | Regarding the release plan, Trident 0.11.0 will be released following the v4.8.1 rollout, and we will update the developer documentation accordingly. 74 | 75 | - **Murphy** 76 | 77 | Is there a difference between `getAccountPermissions` and data retrieval via the original `getAccount`? `getAccount` also contains permission data. 78 | 79 | - **Tina** 80 | 81 | The data source is the same; both retrieve data from `getAccount`. The difference lies in the structure — we converted it into a more usable format. Developers can perform chain calls more conveniently, such as enabling or disabling specific permissions under a Permission ID, which is much more efficient than handling raw Account data. 82 | 83 | - **Murphy** 84 | 85 | A minor question: Trident versions have historically been 0.x.x. We've heard from the community that the version number seems low; why hasn't it reached 1.0? 86 | 87 | - **Neo** 88 | 89 | This is a legacy issue. We may consider bumping the version to 1.0 if there are significant changes in the future. 90 | 91 | - **Murphy** 92 | 93 | Understood. If there are no further questions, let's move to the next topic. Daniel will share the new features in Wallet-cli v4.9.2. 94 | 95 | 96 | **Introducing wallet-cli 4.9.2 features** 97 | 98 | - **Daniel** 99 | 100 | Okay. I'll walk you through the four main updates in Wallet-CLI v4.9.2 based on the Release Notes, and demonstrate how they work. 101 | 102 | First is the new AddressBook function. It allows users to save frequently-used addresses for easy access. As you can see here, entering `AddressBook` displays a table with three columns — Name, Address, and Note — showing your saved entries, along with options to Add, Delete, or Edit them. 103 | 104 | Second, we optimized the USDT transfer experience. Previously, using the `triggerContract` command required manually assembling a lot of parameters — including the receiver address, contract address, and contract method — which was quite cumbersome. Now, with the new `TransferUSDT` command, it’s as simple as a TRX transfer: just input the receiver address and amount. The official USDT contract address is built-in, allowing you to proceed with operations directly. 105 | 106 | Third is the Receiving QR Code. By entering `ShowReceivingQrCode`, Wallet-cli generates a QR code based on the current address. This facilitates mobile scanning interactions, similar to the experience in TronLink. 107 | 108 | Finally, we optimized Account Permission Updates. This addresses the historical pain point of constructing massive JSON strings for the `UpdateAccountPermission` command. We’ve switched to an interactive experience: entering the command now launches a menu with options to modify Owner/Witness/Active permissions or Add/Delete permissions. The design adopts an interaction logic similar to TronLink, eliminating the need for manual string construction. It's much more convenient. 109 | 110 | - **Wayne** 111 | 112 | Is the new `UpdateAccountPermission` command backward compatible? 113 | 114 | - **Daniel** 115 | 116 | Yes. The legacy command (with parameters) still works; the new command (without parameters) triggers the interactive mode. 117 | 118 | - **Wayne** 119 | 120 | Does the QR code display the account currently logged in? 121 | 122 | - **Daniel** 123 | 124 | Yes, it displays the currently logged-in account. 125 | 126 | - **Wayne** 127 | 128 | One point regarding the Address Book: currently, it manages transfer addresses. If I import multiple accounts, when I need to sign — for example, after sending `TransferUSDT` and selecting a Permission ID — the interface defaults to showing only the address. Will the Address Book function be added here in the future? For example, displaying the corresponding Note to help distinguish addresses? 129 | 130 | - **Daniel** 131 | 132 | Currently, it is primarily used for address suggestions during transfers. If a transfer address is not in the book, it provides a reminder. As for displaying notes during private key selection, that is not yet supported. 133 | 134 | - **Murphy** 135 | 136 | Since Wallet-cli supports generating multiple addresses, can we choose which address to generate a QR code for, or is it strictly the login account? 137 | 138 | - **Daniel** 139 | 140 | There is no selection option currently; it only displays the address for the current Login. 141 | 142 | - **Murphy** 143 | 144 | Have the usage instructions displayed when typing `help` in the command line been updated? Do they show the old info or the new usage methods? 145 | 146 | - **Daniel** 147 | 148 | It has been updated. `help` displays usage instructions for both the new and legacy methods. 149 | 150 | - **Murphy** 151 | 152 | Great. Are there any other questions? If not, that concludes today's meeting. Thank you all for attending. 153 | 154 | 155 | ### Attendance 156 | 157 | * Aiden 158 | * Patrick 159 | * Blade 160 | * Boson 161 | * Federico 162 | * Sunny 163 | * Jeremy 164 | * Gordon 165 | * Leem 166 | * Daniel 167 | * Mia 168 | * Neo 169 | * Tina 170 | * Vivian 171 | * Wayne 172 | * Erica 173 | * Murphy 174 | 175 | -------------------------------------------------------------------------------- /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 -------------------------------------------------------------------------------- /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 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/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 -------------------------------------------------------------------------------- /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 40.md: -------------------------------------------------------------------------------- 1 | # Core Devs Community Call 40 2 | ### Meeting Date/Time: June 18th, 2025, 6:00-6:30 UTC 3 | ### Meeting Duration: 30 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/142) 5 | ### Agenda 6 | 7 | * [Proposal: Enable TVM Cancun instructions and Enhance Consensus Layer Verification](https://github.com/tronprotocol/tips/issues/763) 8 | * [Tracking: prepare and manage release_v4.8.1 branch](https://github.com/tronprotocol/java-tron/issues/6342) 9 | * Discuss the scope of TIPs to be included in v4.8.1 10 | 11 | ### Detail 12 | 13 | * Jake 14 | 15 | Ok, let's get started. Welcome to the 40th core developers meeting. Today we have three topics: first, discussing the status of the three proposals opened before 4.8.0; second, discussing the preparation and management of the 4.8.1 development branch; and third, further discussing the scope of TIPs that may be included in 4.8.1. Let's dive into the first topic directly and ask Murphy to share the preparation status of the previous three proposals. 16 | 17 | 18 | * Murphy 19 | 20 | Alright. Can you see the screen? Good. The first topic mainly discusses the three proposals in our 4.8.0. In previous developers meetings, we discussed the order of opening these proposals, and the final conclusion was that they could be opened together. Therefore, we prepared a proposal with the development team and released it in March. After a period of discussion, there are currently no issues. Additionally, in the 38th developers meeting, when discussing the TRX reduction TIP and its opening time, the plan was to open this proposal about one to two weeks after the TRX reduction proposal takes effect. Now the opening time for this proposal is approaching, so please pay attention to the proposal again. If there are no issues, we suggest opening the proposal on June 23rd, next Monday. It is recommended that all SRs complete the upgrade before this date. If the upgrade is not completed, the launch time of the proposal will be postponed. Let me know if you have any concerns. 21 | 22 | If there are issues, you can still provide feedback under Purple. If there are no issues, I will contact the proposal author after the meeting to update the opening time, parameters, and other information. 23 | 24 | 25 | * Jake 26 | 27 | The opening time is set for next Monday, so if you have any other questions, it's best to confirm them by Friday. 28 | 29 | 30 | * Murphy 31 | 32 | Right. That's all from me. 33 | 34 | 35 | * Jake 36 | 37 | OK, let's move to the second topic: management of the 4.8.1 version branch. Neo will share some insights here. 38 | 39 | 40 | * Neo 41 | 42 | Currently, 4.8.1 uses GitHub issues to manage the branch, and the new branch has already been created. The main point is to discuss the timeline for 4.8.1. According to past practices, it might take about three months, but we didn't start immediately after the previous version in May because this version is gradually moving towards communityization, leading to some delays in the process. Now that the 4.8.1 branch has been created, we need to gradually push for code merging for 4.8.1. The tentative timeline for 4.8.1 is from June 1st to August 31st, three months. Based on past testing cycles, we might need to submit for testing 1 to 1.5 months in advance. Therefore, within these three months of June, July, and August, we plan to submit for testing in mid-July. Thus, for the features and PRs included in 4.8.1, please try to submit PRs by early July and have them reviewed to a merge-ready state. Subsequently, if a PR meets the merge requirements, the corresponding PR owner can leave a comment under the main issue of 4.8.1 to push for its merging. When there are new updates to the issues, I will handle the corresponding branch merges. Only after all these tasks are merged will we proceed with testing. The progress of the 4.8.1 branch will be tracked in the issue, and the subsequent steps will be similar to previous version releases. 43 | 44 | After merging to the platform, we enter the QA testing phase. Once testing is complete, we merge to the master branch and then back to the develop branch to prepare for the next version. Overall, the process for the 4.8.1 branch is basically the same as previous development processes. All sub-issues will be linked under this main issue of version 4.8.1. For any new issues or TIPs wanting to be added to 4.8.1, you can leave a comment under the main issue, and I will manage and handle them. Any points that need further discussion? 45 | 46 | 47 | * Murphy 48 | 49 | Previously, we maintained a task file for tracking mainnet version upgrades in the Project, and I saw you used to tag it with 4.8.1, but now the tag seems to be removed. So, going forward, we should focus on the 19 sub-issues under this main issue, right? 50 | 51 | 52 | * Neo 53 | 54 | Yes, that's correct. You can focus on the sub-issues, but there's a problem: PRs without associated issues can't be displayed there. Therefore, for a complete view, you can find it on the Java-tron page of the project. Currently, an iteration cycle called 4.8.1 has been created: https://github.com/orgs/tronprotocol/projects/23/views/2?sliceBy%5Bvalue%5D=4.8.1. All issues and PRs here cover everything included in 4.8.1, which is consistent with the sub-issues. However, since PRs can't be added to sub-issues, development activities with only PRs can't be tracked there. 55 | 56 | Therefore, going forward, whenever a PR is ready for merging and merged into 4.8.1, we will synchronize the merged PR list to the PM's issue. For example, we can list which PRs were merged on a certain day and sync them here as issues, so relevant team members can add them to the corresponding MD file. This way, we can keep both sides synchronized, with PR merging serving as the confirmation of functionality. 57 | 58 | 59 | * Murphy 60 | 61 | Ok, so we mainly need to follow the PM's issues, right? 62 | 63 | 64 | * Neo 65 | 66 | Yes. After merging corresponding PRs in Java-tron, we will sync the merged PR list to the PM's issue. 67 | 68 | Any other questions? 69 | 70 | 71 | * Boson 72 | 73 | I have a question: the three servers for running unit tests and coverage are no longer there, right? 74 | 75 | 76 | * Neo 77 | 78 | Are you referring to the unit test coverage tasks that run every time a CI merge happens? 79 | 80 | 81 | * Boson 82 | 83 | Yes, they existed before, but now the task seems to be removed. 84 | 85 | 86 | * Neo 87 | 88 | Do you know where they were configured before? Maybe we can discuss adding them back after the meeting. Normally, PRs should go through the testing process before merging. 89 | 90 | 91 | * Boson 92 | 93 | Let's see when we can add them back. 94 | 95 | 96 | * Neo 97 | 98 | Alright. Murphy, do you have any other questions? 99 | 100 | 101 | * Murphy 102 | 103 | Yes, regarding the TIPs under the 4.8.1 branch that we need to discuss later, will their subsequent process be the same as issues? 104 | 105 | 106 | * Neo 107 | 108 | Yes, TIPs can also be introduced into the issue. So if there are TIPs to be included, they will be visible in this list and tracked in our project, just like other issues, and synced to the PM side. 109 | 110 | 111 | * Murphy 112 | 113 | Understood. 114 | 115 | 116 | * Neo 117 | 118 | Alright, if there are no other issues, let's look at those TIPs, mainly three related to TVM for Ethereum upgrade follow-up. We won't discuss details today, just confirm whether they can be included in the 4.8.1 version at this time. If not, they can be considered for subsequent versions, though related development can proceed normally. 119 | 120 | Relevant team members can share the status of these TIPs. 121 | 122 | 123 | * Raymond 124 | 125 | OK, there are actually four TVM-related TIPs, plus 6780, which is about the Cancun upgrade. For these four, if we follow the plan of early July to late August (three weeks), there should be enough time to include them, depending on whether all four need to be included in this upgrade. 126 | 127 | 128 | * Neo 129 | 130 | Currently, the most important features in the issues are ARM adaptation, with others being fixes and optimizations. Besides the four TVM-related TIPs mentioned, there are about one or two consensus-related TIPs. Therefore, I don't think we need to include all four TVM TIPs in the next version; including part of them is sufficient, prioritizing stability and development quality. 131 | 132 | For example, the issues involved in 7702 haven't been discussed sufficiently in the issue, so I think they can be further optimized. It involves many aspects, such as contract deployment methods and processes, which can be further discussed in the issue. 133 | 134 | Therefore, in terms of functionality, maybe the Cancun instructions and precompiled curves are relatively less complex. If you feel confident, we can include them first, or you can assess again. Of course, we don't have to include specific items; we can decide based on issue progress. For example, if we need to add two more weeks or a short extension to the timeline (scheduled for mid-July), I think it's acceptable to postpone the version to include the features. 135 | 136 | The premise is that we need to have thorough reviews of the development content, including code reviews, before merging. For TIPs like 7702 that may require a longer cycle, we can postpone them to subsequent versions. So in principle, we can adjust the timeline slightly to accommodate development needs, while postponing larger features that require longer development based on workload. 137 | 138 | Regarding these four TIPs, we can confirm that recently. If they can be included in the next version, just reply under the corresponding 4.8.1 issue, and I will include them in tracking later. 139 | 140 | 141 | * Raymond 142 | 143 | Understood. 144 | 145 | 146 | * Neo 147 | 148 | There's also a consensus-related TIP. In terms of timeline, it should be feasible. No major issues, right? 149 | 150 | 151 | * Daniel 152 | 153 | Yes, the development cycle for this TIP function won't be long, and we should be able to submit the PR by the timeline you mentioned. 154 | 155 | 156 | * Neo 157 | 158 | Great, I'll add it later. Murphy, the second TIP, Multi-Injected Provider Discovery, should not be related to Java-tron. I'm not sure, so please confirm on your side. 159 | 160 | 161 | * Murphy 162 | 163 | Yes, this is related to tronweb. 164 | 165 | 166 | * Neo 167 | 168 | OK, so Java-tron doesn't need to track its progress. Alright, that's all for other items. Let's continue discussing. 169 | 170 | I have no more questions. 171 | 172 | 173 | * Jake 174 | 175 | Any other topics to discuss? It seems we need to confirm whether Raymond's TVM-related proposals can be included in 4.8.1, and the consensus-related TIP is fine. Any other discussions? 176 | 177 | If not, the meeting ends here. Thank you all for attending. Goodbye! 178 | 179 | 180 | ### Attendance 181 | * Daniel 182 | * Raymond 183 | * Sunny 184 | * Gordan 185 | * Elvis 186 | * Neo 187 | * Leem 188 | * Brown 189 | * Mia 190 | * Sunny Bella 191 | * Allen 192 | * Boson 193 | * Blade 194 | * Wayne 195 | * Federico 196 | * Murphy 197 | * Jake -------------------------------------------------------------------------------- /TRON Core Devs Meetings/Wallet Devs Meeting 04.md: -------------------------------------------------------------------------------- 1 | # Wallet Devs Community Call 4 2 | ### Meeting Date/Time: November 18th, 2025, 7:00-8:00 UTC 3 | ### Meeting Duration: 60 Mins 4 | ### [GitHub Agenda Page](https://github.com/tronprotocol/pm/issues/173) 5 | ### Agenda 6 | 7 | * Developer Roundtable: Discussion on [TIP-6963](https://github.com/tronprotocol/tips/issues/737) Finalization and Implementation 8 | * Comply with the TIP-1193 protocol. 9 | * Connect the wallet using the method specified in the TIP-1102 protocol. 10 | * Use the own wallet UUID and keep it fixed among different clients. 11 | * Avoid initiating a connection request when the dApp reads `provider.tronWeb.defaultAddress.base58`. 12 | 13 | 14 | ### Detail 15 | 16 | **Part 1: Opening and Context Synchronization** 17 | 18 | - **Murphy** 19 | 20 | Welcome to the third and final meeting of the multi-browser, multi-plugin wallet integration series. Following our previous discussions, we have finalized the integration scheme for the TIP-6963 protocol. Today's meeting focuses on syncing specific implementation details with wallet providers. Gary will now proceed with the presentation. 21 | 22 | - **Gary** 23 | 24 | Today we will discuss the finalization and implementation key points of TIP-6963. First, a recap of the protocol's advantages: it prevents the overwrite conflicts that historically occurred when multiple wallets injected objects into `window.tron` simultaneously. With TIP-6963, DApps can detect all wallets supporting the protocol, allowing users to discover and use them even if the wallet does not explicitly write to `window.tron`. 25 | 26 | Regarding implementation progress: The TokenPocket plugin wallet and OneKey wallet (both plugin and App) have already implemented the TIP-6963 protocol. I will now focus on four key implementation points for wallets that have not yet integrated the protocol. 27 | 28 | **Core Technical Specifications** 29 | 30 | - **Gary** 31 | 32 | First, the injected `Provider` must adhere to the `Provider` defined in the TIP-1193 protocol. 33 | 34 | Second, wallet connections must uniformly adhere to the TIP-1102 protocol and use the defined `eth_requestAccounts` method. Prior to TIP-1102, developers used `window.tron.request` or other methods. To standardize injection and align with the Ethereum ecosystem, we require the unified use of `eth_requestAccounts`. This allows developers to use a single method to execute connection operations after detecting wallets via TIP-6963. 35 | 36 | Third, we recommend that wallets use a fixed UUID. The TIP-6963 protocol specifies an`announceProvider` event that must emit the wallet's UUID. Our research into EVM wallets revealed significant inconsistencies in EIP-6963 implementations: some UUIDs are permanent; some regenerate on page load (but persist per session); others, specifically some plugins, regenerate upon every App refresh. This inconsistency makes it difficult for developers to identify specific wallets via UUID. Therefore, we suggest maintaining a fixed, one-to-one mapping between the wallet and its UUID to facilitate accurate identification. 37 | 38 | - **Aaron** 39 | 40 | Does this imply that different clients, such as Plugin, Android, iOS, should also share the same fixed UUID? 41 | 42 | - **Gary** 43 | 44 | Yes, we recommend maintaining consistency, as the UUID represents the wallet's identity. 45 | 46 | - **Da Chen** 47 | 48 | I have a differing perspective. Referencing the EIP-6963 standard, the UUID is designed to be ephemeral - consistent at the Session level - rather than serving as a permanent wallet identity. The standard does not mandate it be fixed indefinitely. 49 | 50 | - **Gary** 51 | 52 | Correct, the EIP-6963 protocol only requires consistency within the page lifecycle. However, the lack of a unified implementation standard in the EVM ecosystem — where some are fixed, others refresh-dependent, or inconsistent across endpoints — forces developers to write complex adaptation code. We can discuss the potential risks or issues if we were to fix the UUID. 53 | 54 | - **Neil** 55 | 56 | If the UUID is fixed, could another wallet potentially impersonate that UUID? 57 | 58 | - **Gary** 59 | 60 | That issue exists regardless of whether the UUID is fixed or dynamic. If dynamic, the developer cannot identify you; if fixed, impersonation is possible. Currently, there is no absolute anti-counterfeiting mechanism, and there is no mechanism to prevent other actors from emitting an identical UUID. 61 | 62 | - **Da Chen** 63 | 64 | My understanding is that for a DApp, is it actually necessary to bind the UUID to a specific wallet? Does the DApp need to know which UUID corresponds to which wallet? 65 | 66 | - **Gary** 67 | 68 | Yes, it allows for accurate identification, similar to using the `name` property. This is why we propose it as a recommendation, not a mandatory standard. If there are difficulties, other methods are acceptable. We observed that EVM wallet implementations are inconsistent, with each wallet adopting its own approach. 69 | 70 | - **Aaron** 71 | 72 | What are the specific issues if the UUID is not fixed? 73 | 74 | - **Cathy** 75 | 76 | If not fixed, during standard DApp interactions, the user sees a wallet list, but the developer must rely on the `name` property to identify the wallet. These name strings are arbitrary and prone to confusion. Binding the UUID to the wallet significantly improves identification accuracy. Currently, EVM ecosystem identification relies on a mix of names, RDNS, or specific code, making accurate determination difficult. We hope to standardize this via fixed UUIDs. 77 | 78 | - **Neil** 79 | 80 | I have a proposal. Since UUID behaviors vary, can the protocol maintainers set up a GitHub repository? Wallets integrating TIP-6963 can submit PRs to confirm their UUID and wallet information. Would this better facilitate DApp development? 81 | 82 | - **Cathy** 83 | 84 | That is an excellent suggestion, essentially serving as a wallet configuration registry. If we can reach a consensus, we can proceed with this. 85 | 86 | - **Da Chen** 87 | 88 | Regarding the UUID design, I still have reservations. The EIP-6963 protocol on EVM specifies using RDNS for the Provider ID, which is the community consensus. 89 | 90 | - **Cathy** 91 | 92 | Yes, RDNS acts as a valid identifier. However, given current implementation challenges, matching via Name or RDNS often requires case-by-case code, especially since some wallets use different names across different endpoints. From a DApp developer's perspective, a fixed UUID is superior for code standardization and usability. Our proposal is a recommendation for better usability, not a hard protocol requirement. If a wallet chooses not to follow this, they can still implement UUID binding per Session and rely on RDNS; this is technically feasible. Neil's suggestion is valuable, and if we agree, we can adopt that approach. 93 | 94 | - **Gary** 95 | 96 | Given that not all wallet providers are present, achieving full consensus may be difficult. If technical ambiguities remain, we can discuss alternative solutions later. 97 | 98 | - **Da Chen** 99 | 100 | I believe distinguishing via RDNS with `.Mobile` or other suffixes is a viable solution. This only adds a first or second-level subdomain, while the main domain remains matchable. If a DApp needs to distinguish between mobile and plugin ends, the RDNS mechanism can satisfy this, and we might see more demand for this in the future 101 | 102 | - **Gary** 103 | 104 | Valid point. Let's keep the UUID item as a 'Recommendation,' leaving implementation details to the wallet providers. 105 | 106 | - **Cathy** 107 | 108 | Agreed. We will leave it as such. We can discuss further questions or improvements in the community. 109 | 110 | - **Neil** 111 | 112 | If the UUID is not fixed, will the ID return differently across different browser tabs? If so, what is the advantage? Does it improve security or enable other features? The EIP documentation defines the UUID as 'ephemeral and unique per session,' as Da Chen mentioned. Could you explain the specific utility of this? 113 | 114 | - **Da Chen** 115 | 116 | This design allows for granularity down to the session level. For example, executing a complete flow might require an ID to maintain the lifecycle of that session. While I cannot immediately cite a specific use case, this mechanism offers more functionality and higher flexibility compared to a unified fixed ID. 117 | 118 | - **Gary** 119 | 120 | Correct. Our research indicates that DApps do not currently utilize session-level UUID requirements, which is why we recommended using a fixed UUID. This suggestion was proposed for developers who might wish to use UUIDs for wallet identification. The primary consensus remains on the fourth point: reading `defaultAddress` must not trigger a connection popup. 121 | 122 | **User Experience Specifications (Pop-up Logic)** 123 | 124 | - **Gary** 125 | 126 | Moving to the fourth point, which is a mandatory requirement for wallet providers: When reading `provider.tronWeb.defaultAddress.base58`, if the wallet is not connected, it must NOT initiate a connection request. 127 | 128 | The context is that after a DApp retrieves the `Provider` via the TIP-6963 event, it reads `defaultAddress` to check connection status and update the UI. We observed that some wallets, when disconnected, default to initiating a connection request (pop-up) as soon as this variable is read. This causes constant pop-ups for DApps attempting to implement "auto-connect on page load," confusing users into thinking the site is forcibly reading their wallet. 129 | 130 | **The recommended logic is**: When reading the variable, if a connection exists, return the address in `defaultAddress`. If unconnected, set `defaultAddress` to `false` or `null`. Crucially, do not initiate a connection request (no pop-up); simply return the status. 131 | 132 | - **Neil** 133 | 134 | Agreed, this specification is sound. 135 | 136 | - **Gary** 137 | 138 | Additionally, we have provided a TIP-6963 [Test Website](https://walletadapter.org/tip6963.html). Developers can verify detection and connection functionality after development. As long as it complies with TIP-1193 specifications, signing and connection should function correctly. 139 | 140 | - **Murphy** 141 | 142 | Will the content discussed today be formalized into documentation? Do we need to sync this with other wallet projects not in attendance? 143 | 144 | - **Gary** 145 | 146 | Yes. Once the specification is finalized, we will update the official repository's `tips` directory by creating a new TIP-6963 document. This will include the specifications discussed, including the UUID recommendation and connection logic. We will subsequently contact wallet providers for integration. 147 | 148 | - **Murphy** 149 | 150 | Excellent. If there are technical questions later, please discuss them directly in the `tips` repository. That concludes today's meeting. Thank you all for attending. 151 | 152 | 153 | ### Attendee 154 | - Gary 155 | - Cathy 156 | - Aaron 157 | - Da Chen - TokenPocket 158 | - Neil 159 | - Aeeon Li - SafePal 160 | - Yiqun Wang - imToken 161 | - Patrick 162 | - Star 163 | - Sam 164 | - Murphy 165 | - Jimmy 166 | - vic 167 | - Erica 168 | -------------------------------------------------------------------------------- /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 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 | -------------------------------------------------------------------------------- /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 23, 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), done on 2025.04.30. 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), all the SRs have completed 4.8.0 upgrade. 95 | 96 | Estimated Shasta upgrade time: about 7 days (2025.06.03 ~ 2025.06.10) 97 | 98 | - [x] Notify the community to upgrade (2025.06.03 ~ 2025.06.10),the Shasta has completed 4.8.0 upgrade. 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), it has been discussed since 2025.5.15. 109 | - [x] Invite community devs and projects participate (2025.06.07 ~ 06.28) 110 | - [x] Community and SRs review and decide the voting date according to the progress (around 2025.06.14 ~ 06.21), decided to vote on 2025.06.23 during the [core devs community call #40](https://github.com/tronprotocol/pm/blob/master/TRON%20Core%20Devs%20Meetings/Meeting%2040.md) . 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 | -------------------------------------------------------------------------------- /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 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 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 | --------------------------------------------------------------------------------