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: 10/03/2018
==EDIT 19/03/2018 A lot of people are excited about the test TPS achieved by Credits, linked in this article https://medium.com/@credits/the-alpha-version-of-credits-showed-a-speed-of-488-403-transactions-per-second-during-the-testing-ca5c1045577
I think it’s a really good article. They neatly discuss their technical constraints and changes. And I look forward to reviewing their blockchain code (as opposed to the rest of the code reviewed in this article).
A few things to note from the article, are the constraints they mention;
- The environment they were running in was high spec with very low network latency
- They comment on transactions being reduced to 120 bytes for purposes of the test otherwise their disk throughput is 1,387 TB per hour
- They mention removing EDS to reduce package size and increase the throughput (something that in production they have to bring back in)
- Implementation of BFT with trusted nodes
- They also have a very transparent paragraph explaining how in a production environment the TPS would be much lower if there are low throughput nodes or low network bandwidth
So all in all, they make very transparent how they arrived at that throughput and how it relates to real blockchain TPS, and what compromises they had to make to accomplish it, which when considered means their production throughput will be looking quite a bit less.
Essentially their article and video state, they managed a controlled isolated centralized test at that speed and that in production they are expecting less, however given the same test conditions they are still going to try and up their throughput to 1 million.
For now this is just a very clever marketing video, since most people will be too frantic about the TPS, and not actually read the article. That’s why I am actually impressed that they published the article, it shows that they aren’t just marketing hype at least.
I eagerly await them releasing a playable version so that I can boot it up for myself ;)
==
Originally I had planned to skip doing Credits. I don’t really like reviewing a fresh ICO that doesn’t have their code released on github. You have to make too many assumptions. But Credits and their 1 million TPS keep coming up everywhere I look, so finally I decided that perhaps I do need to write down some of the things I have reviewed.
So first off, who is Credits?
So Credits is a blockchain that has managed to achieve 1 million TPS. Now at this point, while it isn’t 100% relevant I feel it is necessary to mention Moore’s law. Moore states that; “ the number of transistors in a dense integrated circuit doubles approximately every two years.” What this meant back in the day is that hardware capacity would double every 2 years. Similar rules apply today in software. There is only a certain amount of improvement that can happen per every cycle. So currently, we have high claims of 200k TPS (this has yet to be truly testing in a byzantine environment), so jumping to 1 million, seems a bit strange right off the bat. So perhaps let’s look at why we have slow TPS?
So in Bitcoin, they introduced Proof of Work (PoW), now PoW is a brute force attack, there is a password that needs to be guessed and we spend cpu/gpu cycles guessing until someone gets it right. The Bitcoin network is designed that this “guess” should always take around 10 minutes. Now this would have meant 1 transaction every 10 minutes or 0.0016 TPS, so how did they circumvent this? They introduced blocks, a block is a grouping of transactions. So now I could pack 1 million transactions into a block (if there was enough space, there is also a megabyte limitation which I will skip for now), then they would have 1.6k TPS (that’s what segwit does for example, it just allows you to pack a few more transactions into the block). So what subsequent blockchains have done is introduce bigger blocks, lower difficulty guesses, and as we are seeing now PoS, dPOS, PoA, PoI, and BFT to increase TPS.
The above is only part one of TPS though, so let’s say you are on a single machine, you could process blocks as fast as that machine could pack blocks. This means you are as fast as the machines CPU. Now let’s say there are 500 machines, each validating blocks, are you as fast as all of them? No, you are only as fast as the slowest machine in the network. All machines (nodes) must reach consensus, so you often find yourself waiting for slower nodes to confirm (this is where longest chain adoption comes in, but again a topic for another day). So now we see we don’t just have the block constraint, but we also have a CPU constraint.
But that’s not all yet, we also have to transmit the data from point A to point B, this we do through the internet using a peer to peer protocol. So this means at the upper limit we have the speed of light (max speed of information travel), but again, we are as slow as the slowest connected machine to the network, which could be a dialup network.
So for TPS, we need a fast packing mechanism, fast CPU, and a fast network to achieve high throughput speeds. If you look at Ethereum and their PoA (I mean Proof of Authority that’s running in rinkeby, not PoA the crypto) then you can see it can fairly easily achieve 10k+ tps, because the hardware, and network of the packing nodes are controlled. TPS is easy when you can control the whole environment.
So how does Credits achieve this amazing TPS, if Moore’s law is against them, the packing mechanism is against them, CPU constraints are against them, and network constraints are against them? Let’s find out;
Ok, so we don’t have their github code, but they do have an alpha Node. So after quite a bit of digging we manage to find;
- Alpha node
- Desktop application node
- Java Wallet
- Alpha platform explorer
- Online Wallet
Next, digging through some of their articles I came across this statement;
“…as a result the Alpha version of the CREDITS platform is already capable of 100,000 transactions per second. Every second, special robots load a huge number of requests into the system to test its performance.”
Every second they say? Huge number of requests they say? Guess the “special robot” is broken.
Let’s start with the node
This is all I ever managed to accomplish. This doesn’t actually do anything by the way, it just keeps trying to connect. Changed firewall rules, gave all exceptions. Tried on different systems. Which can we also mention that this is a Windows only node? So the fastest systems in the world are all *NIX based, but here we are going to get 1 million TPS with a Windows executable? They say it’s developed in C++.
The above is the whole system for the node.
But ok, so the Node doesn’t work, we can’t decompile it, and there is no code to look at. Moving on.
Desktop Wallet time;
Interesting it’s Java, why would the Node be C++ but the client Java? Anyway, it’s great news for us, we can decompile it!
No encapsulation, no structures, no inheritance. Just going to store the account and amount right there in a String. This is very basic coding. No where here does it actually create a wallet, or set a key,
That’s the whole code structure, I can’t find any cryptographic functions, I can’t find any actual key storage or creation. I see some xml forms that don’t actually do anything, and “key creation” is just hardcoded values
This is the key generation;
So all this does, is take a string, put CSx in front of it, then select 29 random characters to follow it. This is NOT how you do key generation. Whomever wrote this code knew nothing about cryptographic functions.
And see that line that reads the public.key from the property file? Here it is, in plain text;
Reading this is similar to looking at a first year CompSci students projects. I’m done with the Java client for now. I can’t stress how bad and non functional this is.
Let’s move on to the online wallet
Built in Angular. On windows. You can see the project was saved in C:/wallet/wallet/frontend. Again I’m just seeing so many beginner mistakes, at least it’s better than being saved in C:/users/…
Ok, this is now just getting really silly. So that’s the private key generation. MD5 of the current data + MD5 of the key you typed in (which has no limitations or security by the way) + MD5 of a random number.
That’s it, no SHA, no curve, no keccak. Just a quick and dirty MD5. I really don’t want to continue looking at this code.
But let’s trudge on.
Oh, did I forget to mention this is all happening over a non secure line? All over HTTP, so all of this can be intercepted while we are at it as well, great for man in the middle attacks…
The public key is an MD5 of the private key. This is extremely insecure and reversible.
More hardcoded hashes. Ok I’m done. I’m sorry I can’t.
Conclusion: This is amateurish code, written by extreme beginners, who are only just now learning how to code. They need to do a complete ground up overhaul of all of their code if they want to accomplish their goals. I don’t know how this will live up to their expectations. Perhaps they just rushed it to try and get something out the door, but even then, this is amateurish and incredibly basic level code.