previous post about quorums<\/a>, the old system requires propagation of each individual vote of each member of a quorum. Propagation means that the votes are transferred to all nodes in the network which then have to verify and store them. This does not scale well and might also cause a variety of problems with consensus.<\/p>\nLLMQs however only require the members of the quorum to perform the propagation and validation of individual votes (signature shares). The final result (recovered signature) is only created and propagated to the remainder of the network when enough votes are collected by any quorum member. Since the final result is the outcome of a BLS based M-of-N threshold signing session, it\u2019s just a single BLS signature. Propagating only this single signature in the network requires a lot less CPU, RAM, and network bandwidth resources.<\/p>\n
As only the members of the LLMQs perform the hard work and there are multiple LLMQs active simultaneously, the overall network load remains well distributed.<\/p>\n
Other Advantages<\/h3>\n Due to the use of BLS, we also get a few more advantages. All BLS signatures are deterministic and unique, which means that there is only one valid signature for every combination of message and keys. This even holds true for M-of-N threshold signatures, which are in the end just normal BLS signatures. The result of a LLMQ signing session is thus deterministic and unique as well.<\/p>\n
These properties are very important when it comes to storing quorum decisions on-chain. Without these properties, malleability problems would also leak into non-transactional features, e.g. blockchain users and state transitions. By eliminating malleability, Evolution can include features which were previously very hard to implement securely.<\/p>\n
LLMQs and Verification of Signing\u00a0Sessions<\/h3>\n LLMQs are created with the help of a distributed key generation (DKG) protocol. The result of that protocol (the quorum commitment) is mined on-chain before activation and actual use of the LLMQ. This means that there is clear consensus about which LLMQs are active and which masternodes belong to which LLMQ. It also means that, unlike the old quorum system, every quorum signing session can be verified forever. This is very important when quorum decisions are mined on-chain or when SPV (or DAPI in the future) wallets need to verify quorum signatures.<\/p>\n
Size of\u00a0LLMQs<\/h3>\n We will support multiple types of LLMQs, which most importantly differ in size and longevity. We have not decided exactly which sizes to use, but we are open to supporting LLMQs with as many as hundreds (e.g. 400) of members and as few as 10 members. It all depends on the use cases and their needs.<\/p>\n
The implementation of LLMQs does already exist and is already very advanced (not just a simple proof of concept). It is implemented to be a platform, or base layer, for future use cases which require LLMQs. Basically, the implementation of new use cases should just call a few functions of the LLMQ platform. These functions are in the style of \u201csign this message\u201d, \u201cdo we have majority?\u201d and \u201cis there a conflict?\u201d. This should make it very easy to implement new use cases as they do not have to deal with the internals of LLMQs, DKGs, signing sessions, and so on.<\/p>\n
Required changes in\u00a0DIP3<\/h3>\n DIP3<\/a>\u00a0will have to be slightly changed to support LLMQs. The DKG process requires BLS public keys to be known and verified before the DKG session can start. This means that we\u2019ll have to use a BLS public key instead of a ECDSA public key for the masternode operator key. DIP3 will be updated when we have made a final decision on which BLS curves to use.<\/p>\nUse Cases for\u00a0LLMQs<\/h3>\n The first and probably most obvious use case for LLMQs is InstantSend. It can be implemented by simply making LLMQ members threshold sign the inputs of observed transactions. If any member of a LLMQ collects enough threshold shares, they\u2019ll create the final result and propagate it to the whole network. With this, the network will only have to propagate one message per transaction input. If a node observes such a message for each of a transaction\u2019s inputs, it can consider that transaction as InstantSend confirmed.<\/p>\n
I\u2019ll post an article and another DIP soon which goes into more detail for InstantSend and how we could improve it with LLMQs.<\/p>\n
Other use cases directly involve Evolution-related features, especially State Transitions. We\u2019re also researching use cases which improve more non-Evolution related features. You\u2019ll see more blog posts and DIPs in the future in regard to all this.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introducing Long Living Masternode Quorums<\/h1>\r\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[216],"tags":[],"class_list":["post-13413","post","type-post","status-publish","format-standard","hentry","category-news"],"acf":[],"yoast_head":"\nDash Blog: Introducing Long Living Masternode Quorums - Dash<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n\t \n\t \n\t \n