The future of Mulitsigs & cryptography on HIVE
Greetings HIVE community! In this post we'd like to go into detail about the underlying technology of HIVE, specifically multisigs, and what changes we need for the L1. As many of you already know, HIVE lacks L1 smart contracts. Not only is this a problem for the community in general, but also creates major pain points for L2s. Luckily, HIVE has always had native multisigs for it's accounting. A native function that can be hit or miss on other blockchains. However, while this is a useful tool for in general use, it has major limitations for L2s like VSC. In this blog I will go into depth about the problem space, and the suggested changes the VSC project is proposing to the HIVE core team.
Counterparty risk on HIVE
Many of you have already heard of this term one way or another. Almost universally, this carries a negative connotation and rightfully so. With many bridge hacks, insecure L2s, it's easy to lose trust in a system, especially when lots of money is at stake. But, what is counterparty risk? And how does it affect HIVE? For starters, counterparty risk is essentially the assumed risk when a user entrusts their funds into another entity out of their control. This can take the form of DEXs, bridges, and even smart contracts. Luckily for us, a good smart contract with no admin keys, securely audited, and on a safe L1 network has almost zero counterparty risk.
On the otherhand, for L2s this is a lot more complicated to answer, while L2s might have perfect security within themselves, to interact with the L1 (i.e own funds), someone or something (a smart contract) MUST own the L1 funds, and thus create the potential for counterparty risk. Typically L2s employ a trusted entity to hold funds for network. This might be a centralized party or a small mulitsig with a few trusted members depending on the L2. Unfortunately, the reality is most of the top Ethereum L2s solely employ centralized custody or mulitsigs that are not under the control of the community. The controlling entity has complete authority and ability to steal users funds. How can anyone say these so called L2s are secure and decentralized? You can't.
On HIVE, we have native multisig capabilities, which is great! Using this technology in combination with a consensus system, we can help reduce counterparty risk for VSC. Making VSC more decentralized and secure than top Ethereum L2s. VSC node operators are actually in control of L1 funds, and not a single centralized entity. With all this in mind, there are limitations. We have a maximum of 40 signers on any multisig, which boils down to approximately 30 signers with full control (for a 3/4 consensus). This is still better than an Eth L2 with only two or 3 signers for entire network of thousands of nodes and billions of dollars. However, it's still not enough to address modern concerns around L2 security.
While this point is not directly relevant to security, the data cost of operating a multisig on HIVE is not practical. As more signers are added to the multisig, the larger the minimum transaction size becomes. Each transaction for a multisig of 30 signer is a minimum of 2kb, which might not sound like a lot, but it's 30x bigger than regular transactions and larger than the average size of 99% of transactions on HIVE. As a result, the large transaction size imposes significant costs to a L2 and adds significant chain bloat with heavy usage.
Cryptography to the rescue!
Given everything above, it's clear that the current approach to multisigs is not optimal for L2 networks. To solve this HIVE must implement Boneh–Lynn–Shacham (BLS) signatures into the L1 network. BLS is very similar to the current signature algorithms implemented on HIVE, except it allows for very efficient signature and public key aggregation. Signature aggregation allows for combining all of the signatures from hundreds of even thousands of public keys into a single one while proving the exact same information. The result is a massive storage space savings for mulitsig operations and allows for a significant expansion of the maximum allowed signers. Mulitsigs on HIVE could easily have hundreds of even thousands of signers inside nearly the same data footprint as a single signature. For VSC, this makes a significant difference in the security of on chain custody.
Technical details
this section goes more into the technical details while still keeping fairly high level. Feel free to comment any further questions below.
BLS properties:
- Private Keys: 32 Bytes.
- Public Keys: 48 Bytes.
- Signatures: 96 Bytes.
Above, are the sizes of BLS private keys, public keys, and signatures. If you are familiar with ECC cryptography, you will notice the public key and signatures are larger than regular secp256k1 or ECDSA algorithms. However, despite the larger data footprint of a single signature, the aggregation of signatures results in siginficant size decrease at scale.
To do this process, the following concepts must be noted:
- A Bitvector - a series of pointers that indicate which public keys signed a transaction. The bitvector is the only part of a transaction that increases in size as more signers are added.
- Key identifier - identifies the entire signing group for a multisig. All signing parties and their associated weights.
- Aggregated signature - signature created from combining all signatures from each party.
Steps:
- The multisig registers all the public keys and their associated weights. This produces a key identifier unique for that particular group. Note: the public keys are sorted in a deterministic order.
- From this point HIVE nodes have enough information coupled with the transaction can verify any signature from any combination of signers
- A transaction is then constructed and signed by several signers in the multisig.
- The aggregate signature is created as a result
- A bitvector is created from the list of public keys involved in the transaction against the entire signer group. This creates a compressed representation of each public involved and scales on the basis of 1 bit per public key.
- HIVE nodes will then use the key identifier & bitvector to compute the combined public key for the signers involved in a transaction
- The aggregated public key can then be used to verify the signature of the newly created transaction.
- The result is a transaction with a constant aggregated signature size and a highly space efficient bitvector
- Using this approach, it allows us to scale to hundreds of even thousands of signers participating in a multisig with significantly less overhead.
- This technique becomes more efficient as more signers are added. For 3 signers, there is only a storage reduction of 1.4x, where as for 500 signers, the size reduction becomes 170x smaller and continues to scale to a theoretical maximum of 520x (1/8 byte per signer vs 65b per signer)
Legend:
- Y Axis: total transaction size in bytes
- X Axis: total number of signers
- Red line: traditional multisig on HIVE
- Blue line: mulitisig using BLS signatures w/aggregation on HIVE.
The graph above shows you how the storage usage of a traditional multisig scales vs multisig using BLS signatures. You can clearly see how a traditional approach quickly skyrockets in size, where as BLS signatures only marginally increase the transaction size as bitvector increases in size. This does NOT take into account gross storage usage of key identifier, registered public keys, or computational costs and only looks at individual transaction size.
Call to Action!
We urge the HIVE core team to implement BLS signatures & aggregation technology into the HIVE L1. We strongly believe implementing this technology would be easier and safer than L1 smart contracts and opens major possibilities for VSC & Other L2s alike. By HIVE implementing this technology, it would join the ranks of Polkadot, Ethereum, and other chains using attempting to build similar technology. We could be one of the first to fully implement this technology and make it directly available to end users.
We also acknowledge there is even more that can be done to further decrease transaction overhead regarding multisig, such as zero knowledge proofs and signed merkle trees. We aim to make this only a fraction of a compressive set of improvements to the L1 for supporting VSC and future projects on HIVE. This is only the beginning
I intend to meet with the core team to present this information directly and start the process of building into the next hard fork.
Resources
https://wiki.polkadot.network/docs/learn-cryptography
https://eth2book.info/capella/part2/building_blocks/signatures/
Socials
Website: https://vsc.eco
Twitter: @vsc_eco
Hive: https://peakd.com/@vsc.network
Github: https://github.com/vsc-eco
VSC is funded by the HIVE DHF. By voting for our proposal below, we can continue building
Sounds awesome and needed.
How difficult do you think it would be to implement these changes?
Significantly easier than smart contracts. This is what blocktrades said about when it was first mentioned on CTT:
https://peakd.com/@sepracore/re-sepracore-s4qkx9
LFG!
It sounds like something similar to Schnorr signatures (granted my knowledge about them is pretty shallow). Do you know perhaps how these compare to BLS?
BLS is similar in concept. However, BLS is a lot more efficient for doing aggregation, requires less communication and is more secure than schnorr signatures. BLS requires no party setup time and can be easily used without any direct communication between signing parties. Only an aggregator is required to turn a group of individual signatures into a valid aggregate signature. Additionally, library support for aggregation of schnorr signatures is abysmal, where as almost every BLS library supports aggregation out of the box (so far in my search). I've already tested BLS quite a bit and it will be part of the VSC consensus system.
Here is a blog post that will describe the difference a better than I can. Both BLS and Schnorr have their tradeoffs. I'd like to eventually see both techniques implemented in HIVE in the future.
https://medium.com/cryptoadvance/bls-signatures-better-than-schnorr-5a7fe30ea716
Hi - which libraries are used in VSC for BLS ? Just wondering how they are from a performance standpoint.
Congratulations @vsc.network! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 200 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Check out our last posts:
STOP
Notifications have been disabled. Sorry if I bothered you.
To reactivate notifications, drop me a comment with the word
NOTIFYI don't think so, dude. Your post is so riddled with errors that I have now lost faith in your team for letting you post garbage like this.
one of those people 😂
Correct, you are "one of those people" who self-votes their comments.
I don't see how it removes counterparty risk for any swapped asset. Do I oversee something?
The goal of this post was less focused on counterparty risk and more on the tech HIVE needs to implement for efficient multisigs. But to remove counterparty risk, the L1 multisig needs a LOT larger number of signers to be secure. Trusting 30 validators vs 500 validators is a huge difference. 30 validators would be a lot easier to corrupt vs 500. Essentially, what we are trying to do is bring the same level of security the L2 already has, to the L1 multisig. Ensuring there is little to no difference between L1 multisig and L2 security and we ensure the operations happening on the L1 are exactly the same as what's happening on the L2.
OK, yeah makes sense.
What if hive outsources smart contracts to something like koin and add a koin address to hive wallets in some way? Since wallets are free, It could be IMO something that is less heavy and makes hive with the social stuff more efficient. Only because of 1+1=3 since every milestone they hit would benefit efficient hive too.
I mean I support also L2 smart contracts on hive, which would be a game-changer for sure. Special hive could become more finance-related and there is the money.
I'm not quite sure what you mean, but as far I know something like that is not possible unless HIVE is completely removed from the picture or if an adapter layer is built in the first place. We are already building VSC to act as that adapter layer and can enable HIVE to hook in with other blockchains must more easily. Now, we need better support on the HIVE side to best enable VSC to work with the L1.
What it sounds like you are trying to say is making a feature where HIVE can login to Koinos and utilize Koinos from keychain or something else. That's already technically possible and doesn't require anything from HIVE core devs or koin either. But that means anything on Koin isn't even remotely connected to HIVE (aside from account), so the benefit I see is somewhat null.
I fully agree, this would be a hybrid solution ( that must not be bad). Native ones are better for sure. With some work the User name wallet part of hive could be like a ENS on it. So people could send to hive user names in some way ( with some work for sure). This would be pretty nuts.
Was just an idea, since it would also fix a softwallet solution for hive ( with some changes).
For sure. The identity side of it is pretty reasonable to do. There is a lot of interop starting to happen throughout the ecosystem regarding identity and more is always better. For example VSC supports offchain accounts and those accounts can be Ethereum based, thus we can also use .eth domains as part of VSC's identity system. So this would be a similar thing here where HIVE would be a unique name for Koin accounts.
Nuts! That sounds pretty cool and a good way to go. More connections generate more value. And hive could become that way the ULTIMATE ENS for other chains.
I like it!
Make I so!
@tipu curate
Upvoted 👌 (Mana: 50/60) Liquid rewards.
!WOC
Keep up the good work with Woc, @vsc.network! kairke(1/5) is appreciative of the time and dedication you've put into writing this post. Your efforts are truly valued.
This post is wonderful! You deserve this gift of 0.2 WGOLD from @kairke. Keep up the exceptional work!
BTW! WGOLD is the token of the War of Clans ecosystem, you can use it to have discounts in all our games or stake it and earn rewards now!
Congratulations @vsc.network! Your post has been a top performer on the Hive blockchain and you have been rewarded with this rare badge
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
You shouldn't have pages that look like this https://vsc-eco.github.io/docs/scalability/tbd
We will get that fixed.