Created by Hart Montgomery, last modified by Danno Ferrin on Jan 20, 2022
This was a difficult quarter for Ursa–probably the worst quarter for it ever. Not a lot got done due to a combination of factors, which included core contributors being too busy to contribute (or, in some cases, people leaving contributing organizations) and the holiday period slowing everything to a crawl.
However, not all is gloom and doom: there is renewed interest from end users of Ursa (particularly through Aries) and we will do a security audit soon. As such, we are planning on soliciting contributions from companies related to these end users (i.e. people using Aries) and some of these folks have already agreed to help (thanks Cam and others!). This transition will not be immediate but hopefully Ursa will come out of it stronger than ever.
We are also still planning on incorporating some rather large contributions soon (hopefully by the time you will be reading this), including a nice new zero knowledge framework. These have just been bogged down due to the holidays and lack of contributor availability.
- Have you switched from master to main in all your repos ? Yes.
- Have you implemented the Common Repository Structure in all your repos ? No, we are undergoing a (very slow) migration to a different repo structure and things aren’t totally done yet, so we haven’t modified the old repos to support the CRS. Sorry about this. The new repo structure will have the CRS implemented though.
We don’t have any current issues or questions for the TSC.
We say something like this in pretty much every report, but we want to reiterate that we are always interested in getting in touch with others who want to use cryptography, and particularly so for people that want to use non-standardized crypto like threshold signatures or zero knowledge proofs. If this describes you, please feel free to get in touch with us.
Yes, that was a cut and paste, and yes, we will continue to post it. Please talk to us!
We were planning on releasing this quarter, but did not get around to it due to the aforementioned issues. We are planning on rectifying this in the next quarter.
Our communication channels continue to be relatively active (they’re obviously not Fabric-levels of active, but for us, things move). The email list doesn’t see a lot of traffic but we get a number of questions on rocketchat that are usually answered quickly.
Our big code contributions got stalled. We plan on getting these in soon. In particular, we expect to add to Ursa some exciting new zero knowledge proof functionality in the form of a “compiler” that takes R1CS representations of statements and can “compile” them into ZK proofs using a number of different backend systems. This will enable us to keep high-level, application layer crypto code the same while switching ZK backends as the ZK proof systems themselves improve and change. Although this has not been contributed yet, we have talked extensively about it, and certain members of the Ursa community (Avradip, and especially Mike) have spent a lot of time on it.
Our immediate plans involve getting our new ZK code merged into Ursa. This should allow people to use ZK proofs more easily, and we know th”at some companies that use Hyperledger are planning on putting this library to work in practice (Fujitsu, for one). We also have a backlog of some relatively routine maintenance work. As we mentioned before, we also are planning on working on a security audit soon.
Assuming we have bandwidth, at some point this year, we’ll work on adding post-quantum implementations. The timeline for this depends a bit on NIST though. We also need to see when people start demanding post-quantum crypto, as this hasn’t happened to a large degree in the blockchain space yet (possibly because some post-quantum protocols, like zero-knowledge proofs, are extremely expensive computationally).
In terms of community management, we our discussing with Ry and David B about how to better do community outreach so that we can find more contributors and users. We recognize that it is hard to find talented cryptographers and cryptographic engineers with time to contribute, but we need to expand our contributor base and so are going to make a concerted effort to do so.
Mike Lodder (Independent)
Brent Zundel (Evernym Inc.)
Dan Anderson (Intel)
Cam Parra (Kiva)
Hart Montgomery (Fujitsu)
Dan Middleton (Intel)
We have more maintainers, but this is the group that generally participates actively.
It’s not pretty, but hopefully will be better next quarter.
We don’t really have much to add. This quarter has been a struggle but we aim to turn things around soon.
- ✅ Angelo De Caro
- ✅ Arnaud J Le Hors
- ✅ Artem Barger
- 🔲 Arun S M
- ✅ Bobbi Muscara
- ✅ Danno Ferrin
- ✅ David Enyeart
- ✅ Grace Hartley
- ✅ Hart Montgomery
- 🔲 Jim Zhang
- ✅ Kamlesh Nagware
- ✅ Nathan George
- 🔲 Peter Somogyvari
- ✅ Tracy Kuhrt
- ✅ Troy Ronda
Hi Ursa Team,
Ursa project is all about " A shared cryptographic library that enables people (and projects) to avoid duplicating cryptographic work across projects, increasing security in the process." and mainly to avoid duplicating efforts of cryptographic work across projects, right? URSA project at which stage now to use with other hyperledger projects? I think URSA is great project when it prvoides this feature to any blockchain project to use URSA library for modular cryptography.
I think this year 2022 URSA project should be in state to use with other hyperledger projects who are need in modular crypto service.
Just checking and going through fabric RFC which is working on modular crypto-service in fabric.
Posted by knagware9 at Jan 04, 2022 09:34
Yes, you are right. The goal of Ursa is to serve as a modular crypto service, and that is generally how it is used by projects and code th"at do currently use Ursa.
One of the biggest reasons that Fabric hasn't used Ursa at all is the difficulty of calling Rust code from go code. It's pretty common to call Rust code from C code, but unfortunately all of the C to go interfaces (at least the ones that I know, anyway) have a ton of overhead and are not very practical to use. There has been some work on a go wrapper for Ursa, but the developers working on that have ceased contributing. More fundamentally, Fabric also doesn't use a lot of "fancy" cryptography like threshold signatures or any kind of proofs, which are the most commonly used features of Ursa. Projects like Aries or Indy that require these more complicated crypto primitives are typically the kinds of projects that use Ursa.
You can also see my comments in that RFC you linked on the Fabric modular crypto service. I think they still stand, even though they are quite old at this point.
Posted by hartm at Jan 04, 2022 19:37