Good Evening Radix Family!
I’m following Radix since many years, passionate about Dans work and vision, and as we all I am very excited about the recent Hyperscale Test that we’ve been waiting for for so long.
As it finally happened I’m left with some open questions, as I might not be the only one I feel like sharing some thoughts.
I hope this is the right place to do so, as I’m not involved in the Hyperscale group and as Radixtalk kind of comes back to life again, maybe we can have some discussion here about the test that passed, and how to present future tests that might eventually happen.
To put my comments and questions in context: I think these public Hyperscale tests are enormously important, as the linear scalability of the cerberus consensus is imho the single most important property of the radix full stack, if it can be convincingly presented it can be a powerful marketing instrument. One important point of these tests should be to present it in a way that convinces people that its real, no fraud, and that ideally lets them understand a bit of the underlying technic. And imho it should be done in a way that also convinces the tech-savy, sceptical viewer.
I think the public test should produce a nice and moderated live-stream video, that can explain a newcomer what is presented, and why this is so revolutionary.
Í would have enjoyed some explation during the stream, touching amongst others the following topics:
-
The total throughput in the dashboard seems like a multiple of the respective shard throughput. All nodes show different total throughputs, its always sth like 126x[shard throughput]. I cannot make it make sense for me and it seems misleading. I would have thought total throughput is commonly understood as the throughput of the total network. In the entirety of the network commited atoms per second. The whole network never reached 800 kSPS, there was ONE SHARDGROUP (#114) that had a peak of 6372 sps in Guilhermes stream, and that got extrapolated to the “total throughput”. Shouldnt total throughput by definition be the same number on all nodes?
-
This leading to the next point: If an atom touches for example 3 shardgroups, then it will be counted 3 times in the local throughput number (in each shard where the respective states lives), but it should obviously be counted only one time in the total throughput count, as its still only one atom beeing processed… So assuming every Swap involves 3 shards, the total throughput would be roughly (Sum of all local shard throughputs)/3. (Shouldnt a swap always involve 3 states? (Token A, Token B, Pool)?)
-
What is actually measured? Show the Spam production! How many shards are involved in one Swap? How does the Radix concept of a fix shardspace and the automatic assignment of states work? What about the cross-shard ratio? Does 1.000 mean that all Swaps are cross shard? Or none? Cannt also really understand the Tx count, all nodes see different total transactions, and its always roughy the same as 125xlocalTx. Wouldnt that mean that per Transaction always only one shard is involved? Is this even possible with swaps?
-
Would have loved to hear some explanation about how many nodes involved, how many shards, how many nodes per shard, 2f+1 rule, these kind of basic consensus things, that might seem obvious and boring to us, after having listened to Dan endless hours, but for an outsider that should learn to appreciate the work thats been done, thats important information, thats the questions interested people might have.
-
What happens if a shard dies? Does the Spam still include states that live on these shards, and therefore fail? So if 3 shards out of 128 die, shouldn’t a few % of all ongoing Transactions fail?
I’m left a bit confused with the test, without explanation it almost looks to me like as there were no cross shard transactions happening. Total transaction count and total throughput seem like just extrapolated from the local transaction count, times the number of shardgroups.
I think if there will be another test happening in some future, it would be helpful to present the code of the spam production, to put some work into the dashboard, be sure about the meaning of every number that showes up there and give a nice explanation while performing the test, this could probably increase the marketing value of a successful test quite a bit.
To me personally the actual numbers dont matter. Its far more important to show that the setup really scales linearly, and that it really behaves as expected, especially if things go wrong, shards die, and so on…
Would be wonderful to actually see the percentage of failed transactions rise in the same ratio as expected by the amount of crosshard transactions, the moment a shardgroup dies.
Would be fantastic to kind of start with a setup where all the nodes spread to only, for example 2 or 3 shardgroups, with dozens of nodes per shardgroup (much more robust local consensus that allows for more faulty nodes and would allow for showcasing the spectecular recovery if too many nodes in one shard go offline, when the local consesus switches to PoW and starts to recover) and then change to more shards, less nodes per shard, resulting in higher cross-shard-ratios, until the minimum of 4 nodes per shard, maximum throughput, minimum stability, as it seems was used in the test setup.
And see the changes in local and global throughput, finality, etc… Whatever number is reached in the end, even if it would be just some 10.000, it would be still the absolut killer, revolutionary, one of a kind, as it would make it obvious that with this technology unlimited demand could be served, just add nodes.
This would have a much bigger impact, could be much better exploited marketingwise, than just running for this one number, with somehow incosistent or at least for me not understandable numbers on the dashboards.