Alrighty then, back to important facts regarding this shitcoin.
I doubt you would ever be able to understand any of this, but hey I'm gonna leave it here anyway.
So I thought I'd do a translation and commentary on the Credits second alpha test Medium post (
https://medium.com/@credits/the-alpha-version-of-credits-showed-a-speed-of-488-403-transactions-per-second-during-the-testing-ca5c1045577). Below are just my thoughts and observations. Quoted passages throughout are verbatim from the Credits team post.
QUOTE: "The platform node was deployed on a virtual machine in Microsoft Hyper-V for x64-based systems. The hardware specifications were the following: Intel® Xeon® E5–2630, 15 MB cache, 2.30 GHz, 7.20 GT/s Intel® QPI, Turbo boost of 2.80 GHz, 8 GB RAM.
The virtual platform configuration involved the creation of 29 nodes and 1 signaling server with the processor speed from 2.2 to 2.8 GHz."
They mention this themselves later in the post, but this is pretty feeble hardware for a performance test. But the really eye-opening bit is that they are running all 30 nodes on just one processor (6-cores). This is a serious limit on both the amount of load generated and the validity of this as a test. There is literally NO network overhead modeled in this test. Some might argue that, they must have used other system to run the client robots to generate the actual load. This is never stated, and even if true there is no modeling of network overhead to reach consensus or to transfer blocks between nodes.
QUOTE: "The main objective of testing was the ability of network architecture to manage and process large volumes of transactions. That was the asynchronous transaction processing by all nodes on the network due to multi-threading operations. "
Of course there is a hard-limit on the possibility of multi-threading when you're running 30 nodes on just 12 threads (6-core processor + hypertheading).
QUOTE: "In total run, the test was accomplished about 30 times and consistently went from 300 to 500 thousand transactions per second, due to the fact that such a number of transactions occupies up to 385 MB of memory (500 thousand transactions per second). The transaction has a maximum size that is reserved in the database, i.e. up to 808 bytes depending on the balance, the length of the address, the transaction currency, availability of digital signature, etc. We have decided to cut the transaction to 120–150 bytes in order to simplify testing. Otherwise, we would have had to deploy very powerful nodes with a high network bandwidth and a large storage. For example, for 1 hour at 500 tp/s the volume would amount to 1,387 TB."
I pointed this out in chat groups. The storage requirements of the Credits system are out of hand. First off, since they've removed Merkle trees from their blocks, there is no transaction pruning. I have also confirmed via their Telegram group that all nodes are expected to store all blocks. So let's run the numbers:
400k TP/S * 135 bytes = 54 MB/s. That translates to 4.6 TB/day . And that's with their faked reduced load. Their max transaction size is 808 bytes, so a more reasonable average of 404 bytes per transaction yields: 13.9 TB/day in data.
QUOTE: "The absence of EDS. We were tasked to test the load on a stable version of the platform. EDS requires additional processing time and adds 64 bytes to the volume of one transaction. The function is implemented in later versions of the platform with the use of technology EB25519..."
I'm guessing they mean an "Encrypted Data Store" since they never expand out the acronym. So all of this is without encrypting/storing the data. I'm pretty sure this isn't what they mean since they then mention "EB25519" (sic). I think they mean EC25519 - elliptic curve key agreement. Which is not for encrypting data as they suggest but for creating public & private keys. So this statement is either opaque or just nonsense. But let me take them at face value and just add that 64 bytes of data to the previous computations.
So we now have the following transactions sizes 184 bytes (min during testing), 468 bytes (average?), 872 bytes (max). Yielding daily storage requirements of: 6.4 TB/day, 16.1 TB/day, 30 TB/day. It's worth noting that each node needs a download speed of 3 Megabits per second (Mbps) to keep up with the max data rate. And this is assuming only 400k TP/S.
QUOTE: "Validation of nodes. We refused from the validation algorithm DPOS and implemented a stable version of the validation algorithm BFT. During the testing phase, it was decided to use a stripped-down, but a stable version of this protocol."
So they didn't implement their proposed dPoS (dPoW??) algorithm, instead using a stable version of BFT? So this test does not actually reflect running their own proposed solution, but some other solution that they don't really specify. BFT (Byzantine Fault Tolerance) is the name of the problem, not the solution. The one solution ("Practical Byzantine Fault Tolerance" (PBFT) by Castro & Liskov -- Wikipedia) is an example of a solution. There are others, but stating "BFT" does not give any clue to the correctness, viability, speed, or applicability of the solution they used. Furthermore the resulting performance of the consensus (which must be reached by some majority of the nodes) is not reflective of their final solution. The consensus algorithm is the key bit of the system, it's the "crypto" part of cryptocurrency. I'm not sure how anyone is supposed to determine the viability of their system when it doesn't contain critical parts of the code they intend to run.
QUOTE: "The checking of transaction uniqueness was performed without checking the account balance. It affects the speed only to inconsiderable ~1–2%, but we would have to create a lot of different accounts."
Wait, that means there was no checking for double-spending. Hell there was no storage and updating of account data. So the memory requirements of that subsystem are also absent from the test. While the time required might be low, the actually memory usage can be significant. If the memory usage exceeds the capacity of the node (which is likely at these transaction speeds) the total time while grow exponentially as the nodes start switching to virtual memory (which can be 100-1000x slower than RAM).
QUOTE: "The following issues were also absent as not required for testing the system bandwidth: - Charging of fees for processing to the main and trusted nodes; - Processing related to smart contracts;"
Uh right, so all of this ignores the actual performance costs of running smart contracts. In fact, I asked in their Telegram group where/when the virtual machines (VM) for running smart contracts would be running (never addressed in their white paper or technical paper) and never got an answer. The whole system will slow down drastically when they need to start running transaction that are more than just moving Credits from one account to another.
QUOTE: "The speed is also reduced as the load on the network increases."
They casually toss this in, and follow it up with:
QUOTE: "The environment always greatly affects the network bandwidth, and the same applies to the network load. The rule is always the same regardless of the complexity of the system."
Right! So they decide to test all of their nodes running on a single server running in virtual machines? There is no real Internet delays, no lag time, no bandwidth restrictions. The test they ran is an optimal speed test, not a real performance test. Their optimal speed is an AVERAGE of 100-1000 TPS, which is inline with the performance we see from the likes of STEEM and BitShares today. While they manage 1 second long peeks of 400K, that is in no way a sustained rate. But all of that assumes an unrealistically fast/reliable network, which the real Internet isn't. Besides they're not running their production code, but a stripped down version without a version of the critical component (dPoS/dPoW).
QUOTE: "We decided to remove the response request from the connector. However, this step increased the risk of data loss during the synchronization. At the same time, there emerged some problems with the data transfer protocol: the maximum packet datagram of 65,535 bytes for the UDP Protocol did not permit transmitting larger packets. Packet sizes were restricted to maximum size of the datagram to solve both of these problems, i.e. reducing the loss of data during transmission and increasing the speed of processing."
Sigh. Again, this was an optimal network. UDP is not reliable, the Internet prefers TCP since it guarantees transmission (unlike UDP). Max size UDP packets run the risk of being dropped by routers on the Internet due to fragmentation/errors. Dropped UDP packets are just lost, and the servers are required to recognize the problem and resend. That's the "response request" they dropped from the test. Which would have slowed down their system! UDP is great when an unreliable data stream is acceptable (Eg. video). If one or more packets are lost, things like YouTube can just stall for a fraction of a second and continue playing, sometime unnoticed. I don't think you want your cryptocurrency failing to send synchronization packets between nodes. The result is delayed transaction times and the possibility of double-spending errors. In the case of slower protocols (BTC, ETH) where are are often large amounts of times to resend data (10 mins, 30 seconds respectively) UDP is probably acceptable. Credits is targeting 0.1sec. transaction times -- there isn't time for multiple resends between confirming nodes. Remember 51% of the trusted nodes have to agree on the ledger for a transaction to have a single confirmation.
QUOTE: "The average minimum time of passing a transaction record into the database is 1.302 microseconds ( 10 –6 sec) (transfer between nodes, processing and preservation in the storage). "
That's "average MINIMUM time" (emphasis mine). That of course is transfer between nodes RUNNING ON THE SAME COMPUTER AND IN PARALLEL THREADS ON DIFFERENT CORES! For freak's sake, that's no way indicative of even optimistic processing on a real network. For comparison, sending 56 bytes of data 8 feet on gigabit ethernet takes 450 microseconds, or 300 times longer. That's no router, no "real" Internet. Just a quick UDP transmit from my desk to the router in the corner.
Look, can the Credits team build a system? Probably. I think they still have a lot to learn about cryptocurrency, but they can learn it a build something. Will it handle 1 million tp/s in the real world? No. Will it handle 100k tp/s in the real world? Not likely. Will it handle 10k tp/s (peak) and 1-2k sustained? That's a possible outcome WITHOUT smart contracts. Which would make it approximately as fast as some of the non-contract capable blockchain solutions out there today. Will this team implement secure smart contracts, reliable/secure transactions at 1000+ tp/s? I don't think they'll be first or best at it.
It's all lies and bedtime stories kids. No matter how hard you try to shill, it's still only a shitcoin made to steal money from ignorant people.
