Network upgrade using BLS signatures for Confidential Transactions

Hi folks
As we’ve mentioned informally a few times, we’ve been looking at using BLS signatures as part of a network upgrade. Before bringing this to the community as a potential option, we wanted to see what it would really look like in terms of the technical issues and how feasible it would be. This meant developing and testing a certain amount of code so that we could present something concrete for people to chew on.
As with most things there are trade offs involved and it’s not necessarily a slam dunk obvious decision.
In order to get the ball rolling on discussions, I’ve put together a couple of Medium articles for people to read.
Also, note that not everything is done yet and there may still be some delays in pushing this all to the mainnet if we decide to go ahead.
Obviously, we think this is worth going ahead and the benefits outweigh the risk, but ultimately it’s a community decision.

1 Like

Having spoken to Spock a bit about this, I would like to see others put forward questions about this proposal as proteus, myself and spock already understand it mostly.

Yes, please ask the tough questions now. Don’t be the guy asking in 3 months, “why didn’t we do …” or “why did we decide…”

http://69.90.132.202:3002/block-height/839
This shows for Testnet what an aggregate Tx looks like. That example shows 100 individual transactions that have been combined into 1
since for example there are a few inputs with 503 DVT, you can’t tell which ones correspond to the corresponding outputs.
i.e several 491 outputs and even more 10 outputs (2 for Fee)

Thanks for the article, it’s an interesting read and while I dont have the level of knowledge required to determine which is the better route, i can appreciate the need to stand out from the crowd. Surely the best time to try something new such as this would be before any other way was truly established, so it sounds good to me.

The way you described how the greater privacy is achieved was great, made it very easy for me to visualise.

Just to get some more understanding,

BLS signatures are not free from issues, however. Time wise, the process of signature aggregation and verification is quite a bit slower in BLS compared to Elliptic curves/Schnorr signatures. See [3] below for example comparisons. Initially for DeVault this is not a big concern since we are not yet dealing with high transaction loads.

What would happen if DeVault would see high transaction loads, like the spam we already had?

1 Like

Dash had a stress test and chainlocks failed at one point on testnet i assume due to alot of mns having been hosted on 1 cpu core nodes.its possible alot of spam txes may cause alot of high cpu usage on nodes with low specs

We’d be in the same situation as before and for BLS the CPU load is likely higher. We’ve done some testing of this nature but don’t have any documented results yet. We should provide this information though so it’s not a concern.

http://69.90.132.202:3002/block-height/830
Sorry, apparently a typo meant I referenced the wrong block before

Plan for DeVault will be a phased update to phase in BLS addresses and slowly phase out legacy ones.

BLS code is cloned from Chia networks and they are currently updating it so that it will be compliant with a standard. So we will update that as long it it is ready fairly soon.

We’ll also try to provide various performance metrics before a vote is put up.

Ideally, we’ll hire someone who has good blockchain experience to review the code for potential issues since this is a significant update.