# Setonix: Blockchain-Based Hierarchy Domain Name System for Web3
## 6 Experimental Results
The patterns seen with the two methods, local resolver and Setonix, are almost identical to the graph in Figure 6. What is particularly noteworthy is that, as expected, the resolving latency approaches zero as the number of attempts increases due to caching. Meanwhile, even with the algorithms currently in use, the internet usage of the average user is somewhat limited to a restricted area [29]. Through this, even when using a system with a relatively higher average resolving latency, the effect of caching becomes more pronounced due to the limited range of access typical for users. In the end, the combination of a cache-enabled proxy-based interface and Setonix, like the local resolver, is unlikely to cause significant latency-related inconveniences for users. Figure 10 shows the Query Per Second (QPS) measurements for each DNS, using the DNS load analysis tool dnsperf [30]. The experiment utilized dnsperf on an AWS EC2 t3.medium instance (2 vCPUs, 4 GB RAM), running Ubuntu 22.04 in the Seoul region. Requests were routed through the Setonix proxy client on a PC with the specifications outlined in the first paragraph, also located in Korea. What can be observed from the graph is that Handshake's higher latency is also reflected in its lower bandwidth, which could cause inconvenience for many users. In contrast, Setonix demonstrates over 10 times better performance, and while it does not match conventional DNSs, it offers much better usability compared to existing blockchain-based DNSs. Although the reduction in bandwidth caused by the custom resolver in the Setonix Interface may seem significant when looking at the graph, this interface is installed and used locally by each individual. Therefore, the bandwidth reduction does not impact the usability of the system for individual users. Although we wanted to include experimental results for registration time, it was not feasible to measure it, as the registration process in each DNS involves multiple steps and can even include a waiting period of several days. However, with Setonix domains, registration is completed the moment a registration request is sent along with the necessary data for the contract, indicating that it can be considered to other DNS systems in terms of performance and convenience. However, as mentioned at the beginning of the Experimental Results section, the testing environment is not based on Ethereum's main net but on the Sepolia test network. Figure 9: Results of performing six consecutive resolving attempts for each DNS without flushing the cache. In this figure, please note that the data for Google Normal (light circle symbol) overlaps with that of Google Setonix, making it visually indistinguishable. Therefore, the data for Google Normal can be considered nearly identical to that of Google Setonix when interpreting the graph. Therefore, differences in results due to network scale should be taken into consideration. Additionally, the number of domains registered for testing was around 100, and the maximum number of concurrent users tested using dnsperf was limited to 100. Considering the scale of these tests, it is important to note that these numbers are far below what would be expected for an actual service environment. Nevertheless, blockchain-based systems inherently possess good load distribution performance due to their decentralized nature, allowing services to be provided across multiple nodes. This characteristic suggests that they are likely to exhibit performance not significantly different from the current results, even in large-scale scenarios.