[How-to] Convert Block level DB to ROCKS DB

This guide is intended for those who wish to convert from one DB format to another. The benefits are:
– You can use RocksDB as storage engine when you want to back up the database without the node application stopped,
– The Rocksdb engine has more tuning parameters for faster-synchronizing block and takes up less disk space when compared with the Block LevelDB.

Note:
You must only use one db engine (leveldb or rocksdb) throughout the life cycle of node because rocksdb’s data structure is incompatible with the leveldb’s. A convert tool is provided within Java-Tron to convert the leveldb data to rocksdb data and the usage of tool is described below. Please be aware that the conversion take time and the node is not syncing any blocks while this operation is ongoing.

1. First we need to clone the git and build it

git clone https://github.com/tronprotocol/java-tron
cd java-tron/
./gradlew build

Just wait until it’s built and tested. Go grab a cup of tee or a coffee.

2. Then we need to stop the node
3. Now we need to use this Java converter package (DBConvert.jar) to perform the conversion. It is located here: /java-tron/build/libs/

Sample syntax looks like this

java -jar build/libs/DBConvert.jar  your_database_dir/database  output-directory-dst/database

Example syntax looks like this

java -jar /home/userdir/java-tron/build/libs/DBConvert.jar /home/userdir/FullNode/output-directory/database /home/userdir/FullNode/output-directory2/database

According to tron documentation it should take about 10 hours to finish the conversion. Well on my node it took about 67800 seconds. This translates to 18.8 hours. The process is not CPU or Memory bound, both my CPU and Memory usage never exceeded 10% or the allocated resources.

Case Study – The Missing TRX

A Reddit user found a Dapp called FomoSports and played it. He then saw that he was missing 80 TRX, that could not be justified in any way.

This is his address: TBhLhTP4Mscgj5gpMxfe6u1zsWQ3DzEGMi

How he explained it with his own words:
a) The deal is open a Tronlink wallet to receive 50 TRX to play, and after betting let person know to get another 100TRX.
b) My friend lost the 30TRX of the 50TRX then received another 100TRX. Then he played another 10×3 (30TRX) should have 90TRX left.
c) However, my friend told me that he only have 10TRX left in his Tronlink.

It is shown in these 3 screenshots below.

Transfers

 Transfers. 50+100 = 150 TRX

 

Transactions

Transactions. This is the SUM of the amounts +50 -20 -10 +100 -10 -10 -10 = 90

 

final amount

Final amount in the Tronlink Wallet = 10 TRX

 

This is what happened:

This is because of the energy fees.  The conversion values are listed below.

1 SUN = 0.000001 TRX
1 TRX = 1,000,000 SUN

Let’s break it down and look at the contract triggers on TronGrid.

Transaction 1: SUCCESSFUL(-20TRX) with Fee 2.869300 TRX

"energy_fee": 2869300

Transaction 2: SUCCESSFUL(-10TRX) with Fee 3.581450 TRX

"energy_fee": 3581450

Transaction 3: TIMED OUT with Fee 100TRX

"energy_fee": 100000000

Transaction 4: OUT OF ENERGY with Fee 3.549250 TRX

"energy_fee": 3549250

Transaction 5: OUT OF ENERGY with Fee 0TRX (no funds left)

"result": "OUT_OF_ENERGY"

Let’s sum it all up:
20 + 2.8693 + 10 + 3.58145 + 100 + 3.54925 = 140TRX

+10TRX still left in account = 150TRX (all accounted for)

The loss is mainly due to the 3rd contract trigger where the out of time exception occurred and this causes all the input energy to be spent as seen above. This seems very unfair because the actual running of said contract didn’t actually use that much energy (judging by the origin_energy_usage it should’ve been more like 4TRX charged).

The timed out with 100 TRX Fee was unexpected. This seems like a way for TRON to punish people for trying to run smart contracts that take too long to execute. Either that or it’s a bug in java-tron. You as a end user have no control over the smart contract and how it executes as it’s running on the Nodes of the super representatives.

Quick Tron Nodes Sync

Version 2.0 – 04.03.2019

Hello fellow TRON enthusiasts. Dorian here with a new article about how to cheat a bit to speedup the tron sync time for your full nodes. As solodity functions are now provided by Full nodes the below guide has been updated. A full sync takes maybe close to a month for a Full node if you start from zero.

The good news are that the TRON foundation makes backups of the output directories every couple of hours publicly available [HERE].
The size has almost doubled in 5 month since the guide was first written.

You can follow Part 1 and Part 2 of our guide to compile the jar files that you need. Then as an intermediate step you will go to the backup directory and download the files.

The Guide has been updated as content and namic conventions have changed

Old Version naming
 
FullNode-latest-output-directory.tgz               24-Nov-2018 18:16     21G
..
SolidityNode-latest-output-directory.tgz          24-Nov-2018 19:01     40G

New version naming

FullNode-7188305-3.2.4-output-directory.tgz 04-Mar-2019 04:12 93G
..
FullNode-latest-output-directory.tgz 04-Mar-2019 10:13 93G

Instructions below:
You can use wget to get them, then untar, then move then into the proper folder (Ex. FullNode)

 
wget https://backups.trongrid.io/FullNode-latest-output-directory.tgz 
tar -xzvf FullNode-latest-output-directory.tgz 
mv output-directory FullNode

You can also do a chown just to make sure that the user has all needed rights on the files

 
sudo chown -R user:user /home/user/FullNode

Expected time for archive download and untar is around 30 Minutes – 2 hours (depends on your connection speed and peering).

Covered Scenarios:
1. You need to sync a single node.
Just download the archive, untar and start the node software.

2. You need to sync more than one node.
a) Download the archive on the first, untar and sync until it’s up to date.
b) Stop the Tron Java process and scp the entire directory to the other nodes.
c) edit/modify config files and start the java tron process. it will sync the delta’s since it was stopped.

Disaster Recovery Orchestration

TRON Disaster Recovery Orchestration

On the 27th of October 2018 I’ve held a product demo about Backing up a TRON Masternode at “Angajatori de Top”, one of the biggest job fairs in Romania. While announcing the event in the Tron Discord channel, I received requests for a presentation or white paper.

Today I’m happy to announce that the promised white paper is ready. You can get it as a PDF file from here:
TRON Disaster Recovery Orchestration whitepaper