This post describes some wishes I have regarding visualization features for DAG that could bring more intuition and understanding of DAG tadeoff to any new DAGer:
-
A simulated visualizer that is configurable, allowing the user to play with the block rate, the block mass limit(s), the assumed delay in the network (more advanced: the topology of the mining network), etc., and view a DAG growing according to the specified configuration.
-
A rich Rothchild (=Kaspa testnet txgen): The primary effect of the mass limit(s) is on whether the DAG is processing many regular small txns, or few txns with big payload. The latter is more interesting imo, as it is more in line with the current needs of the community (cf. Rollups), and because it keeps the requirement for full node more reasonable, as it only needs to process few (10, say) txns per second. Bottom line is: visualizing the different setups and capabilities requires implementing a txgen with rich features.
-
As a next step, I’d wish to be able to see what the resource consumption would be with such configurations – some rough estimations on the required CPU, bandwidth, disk space needed to run such a DAG in a real node. The estimation could originate from some extrapolation from several real data points (real performance of Kaspad under different configurations).
-
A separate tool that allows for a step-by-step algorithm visualizer of various DAG protocols, e.g., longest chain. Inclusive-GHOST, SPECTRE, PHANTOM. Similar to https://rosulek.github.io/vamonos/demos/index.html
-
A dashboard for the actual Kaspa (test/main) network, monitoring various metrices. Personally I’m interested in (i) the end-to-end time-to-inclusion, namely, the time that passes from the user pressing “send txn” to the user observing the txn included inside some block in the DAG; and in visualizing (ii) the frequency of block creation by small miners, i.e., how frequent a miner with x% of the hashrate would mine a block, and the resulting time-to-inclusion for a user that sends a txn directly to the miner, without going through the mempool. More motivation on this later. The expected value of these items can be provided with over-the-envelope calculations, but we want to see that they admit to their expected value in the actual network.
Other metrics are mentioned in this post. If you have more ideas pls comment below.