「TechTabloid」The “SQoS ”of Dante Protocol
In early articles, we have made brief introductions of Dante Protocol, and we have detailed description of the Service Presentation Layer of Dante. Today we will focus on the SQoS of Dante protocol, which is a necessary part for an infrastructure.
What is SQoS in Dante Protocol
SQoS(Security Quality of Service) is derived from QoS(Quality of Service). QoS is the description or measurement of the overall performance of a service, which is used in many communication kinds of infrastructures, such as a telephony or computer network, or a cloud computing service. The most famous use case about QoS is the TCP/IP protocol suite.
In computer networks, people found that sometimes they need reliable communication, that is, messages need to be delivered with no doubt. But sometimes, they did not care about whether the messages arrived at the target or there were errors. Similar choices happened when people were considering other demands such as bandwidth, latency, packet loss, packet delay variation, out-of-order delivery, etc.
In general, QoS is necessary as different scenarios may have different service demands, so an infrastructure needs to provide a dynamic mechanism to let users make choices according to their scenarios.
SQoS is such a dynamic mechanism adjusting security and efficiency for interactions between isolated consensus spaces. The “S” in “SQoS” stands for security, which might be the top concern in the cross-chain field of Web3.
Without sacrificing decentralization, choices need to be made between security and scalability/efficiency. Different scenarios may have different demands for security or efficiency. For instance, in some cases, token swapping or transferring happens across consensus spaces, the security is the top concern. Other cases like social or game, efficiency might be the most important thing. In the Dante Protocol, SQoS is designed with the consideration of many Web3 scenarios.
Typical SQoS items in Dante Protocol
Details about the SQoS can be found in Dante’s white paper, and some of the interesting parts we’d love to share will be presented as follows.
Hidden & Reveal
From a game theory perspective, under the strategy of majority rule, what is the best solution for an off-chain router that does not actively do evil when every submission is directly plaintext? The answer is submitting the message which is submitted by most of the other routers no matter what the truth is.
This is the typical situation where SQoS item “Hidden & Reveal” comes into play. Before delivering the plaintext message from source chain to target chain, a cryptographic commitment would be submitted first. Commitments from every router are different from each other even if the related messages are the same. The commitment is unreadable to others. The commitment can be checked when the plaintext message is submitted. It’s very hard to construct a commitment with two different messages.
With the help of “Hidden & Reveal”, routers that do not actively do evil will carry the true message because they cannot know what is the majority. In general, this item is used to forbid the nodes who are not bad being forced to do malicious things.
Selection Delay
This SQoS item is special as it’s not a good idea to use it alone. “Selection Delay” means that the working routers need to be selected after enough off-chain routers finish their submission.
Some people said that “Selection Delay” is more secure than selecting working routers before the submission. It looks right, but is actually wrong. Things are more complex and interesting in reality.
It seems that the routers cannot know who will be selected after working, so they do not dare to do malicious things because it’s very hard to collude. But if we think about it more deeply, we will find more interesting things. The trickiest situation in this field is when a message is created out of nothing, in which nothing could be carried by honest routers. That is, if we meet this situation when using “Selection Delay” alone, the target chain will only receive malicious message copies. As a result, no matter which routers are selected, they are all malicious because honest routers won’t submit anything.
“Selection Delay” is still useful when it is used along with other SQoS items such as “Optimistic”, “Hidden & Reveal”, etc. In general, something on-chain is triggered determinedly, this item will come into play.
Error Rollback
This is a very important SQoS item that helps users know whether their remote operations are processed as wished. But an absolute “Error Rollback” is very hard to make out. Consider a situation that when an remote invocation is made from a source chain to a target chain, error happens on the target chain and a rollback reminder is sent from the target chain to the source chain, but unfortunately, the reminder is still error on the source chain, and what shall we do for the next? It is really uncomfortable to engage in an “Error Loop”.
It seems very hard to solve this problem, but Dante did it. We borrowed the mechanism of TCP/IP three handshakes. An error won’t loop forever and the performance consumption is acceptable.
Conclusion
More incredible things will be made out by combination of different SQoS items, and we are preparing a Multi-Layer Gaming Model based on basic SQoS items and cryptographic algorithms, with the help of which more links in the Dante Protocol can be verified with certainty.
The details related to SQoS in the Dante Protocol are not very easy to understand. Generally speaking, when dynamically adjusting security and efficiency, the verification algorithms, the consensus mechanisms, and the message protocol must be involved. So if someone wants to build a flexible enough infrastructure for different scenarios, he needs to design the architecture from the first beginning with the consideration of SQoS like mechanisms.
Join Dante Community
Dante Website | Dante Twitter | Dante Telegram |
Dante GitHub | Dante Discord |
Contact us
Email: Nika@dantechain.com
