Cryptocurrency Code Review: Tron (TRX)

Disclaimer: These reviews are done as is from what is on display in the master branch of the repo’s made available. This review is not a comment on the overall project, scope, or success thereof. This was done as an educational review by me and any comments in the article are simply my opinion. It should not be used as any comment or advice on the project as a whole.

Review Date: 18/03/2018

Active repo, always good to see, two primary projects wallet-cli and java-tron. We will be looking at java-tron

Gradle being used to manage, that’s good to see, lots of commits and branches and 1 core release

Branches look good, they avoid changing on the main stable repo until a branch is passed, this is good development structure.

They use protobuff, it’s a fantastic technology by Google, and I’m glad to see it finally being used in a project. Too many blockchains are creating their own network protocol package layer when this is a problem we have solved for years, ASN.1 and Protobuff being my personal favourite.

Went through all the proto definitions, they are solid.

Full Node, this is the entry point for running a node, just starts up an Application object from org.tron.common.application.*, will have a look at it just now, there are no help guides here just yet, still very much dev only, so this isn’t at any production level ready yet, but let’s focus on the substance for now;

The wallet is a bit odd, it needs an application object to create itself, this means wallets are only running locally on an application, this doesn’t mean anything just yet, just an observation.

I am really not a fan of the UTXO model, I don’t understand why people are implementing it, although at least they abstract balance and then they abstract that for creating transactions, so they hide the part of the implementation I don’t like.

Only witnesses can product blocks, this is a very centralized model, we are seeing more and more centralized systems, I guess it depends on who can be a witness though, ignoring this for now.

Good error handling, unknown exceptions are logged and thrown, this tells us these developers have definitely had production level experience and had to deal with things like kernel panics and out of memory errors, this is good to see.

WitnessService.java code is good. I like the tryProduceBlock mechanism before block creation

Different time implementation than before, shows a bit of inconsistency, but probably just multiple devs working on the project without cross peer review, doesn’t mean anything bad.

Dealing with exception messages is annoying, it’s nicer to have completely different exceptions to map, the change from different exceptions here to a single message based one I’m not a fan of, it makes down stream implementation harder.

Conclusion: Bit of a mix of mid to senior level code, all in all it is good though, there isn’t too much going on here, a p2p implementation, wallet and account implementation, and the witness implementation. Witnesses need at least > 33% participation to vote, and the vote implementation is fairly standard.

It is a long way from being finalized or production ready. I didn’t see the Kafka implementation anywhere, I was looking forward to it since Kafka and Spark are two of my favourite technologies.

In this competitive market I don’t think it’s enough to give them an edge since they are still playing catch up to existing infrastructures without bringing anything new to the game.