Research Spotlight | Where Academia and Blockchain Meet
Why collaboration between researchers and developers is essential.
Research is a key part of what we do at Dusk. From leading the way with new studies to staying up to date with the developments in the industry, our team is always hard at work. But what do researchers actually do, how do they collaborate with the development team, and what do they like most about working at the intersection of cryptographic research and blockchain technology?
Everyone working in the blockchain industry knows how complex the technology is, that the learning curve is steep, and the road is not always easy. Once you're inside, you realise that this complexity does not go away, but rather that new proposals come out every day and that part of our work is to keep up with advances and new emerging solutions. This applies to several aspects of a project: from the base layer of cryptographic primitives that are used, to other consensus protocols, to new improved peer-to-peer communication models, different use cases, and creative user experience designs. The case of Dusk is no different: although we share similarities with other blockchains, very few other projects are aimed at the financial and business framework, and hence there are problems and situations that we face alone.
In our research group at Dusk, we focus on the cryptographic pieces of our stack and the security of our systems. Cryptography is the foundation of any blockchain project: digital signatures - which are used to authenticate users -, hash trees - which are used to store data and ensure its integrity-, or zero-knowledge proofs, which allow verifying the execution of computations with private data, are all cryptographic structures. Our team is in charge of designing new protocols for our use cases, but it must also ensure that both the cryptographic building blocks we use and the models we construct on top of them are solid, secure, and efficient.
If we think of Dusk as a building , the work of the research team would be similar to that of the architect in the construction project. Faced with a set of particular needs and requirements, the architect's job is to design a building that satisfies those needs and does not fall. When starting a new project, an architect does not really start from scratch but actually carries a bag of knowledge that includes the building materials that can be used, the loads that the pieces can withstand and the security they provide, standard designs for different chambers, etc. Similarly, all members of our team have a strong background in cryptography and we use our knowledge to build new protocols adapted to the needs of Dusk. Just as an architect must speak with the quantity surveyor and the builders, we must coordinate with the development team who will later implement our proposals. To expedite this process, our team also includes members with a hybrid profile, with both theoretical knowledge and programming experience.
Even after a project enters a development phase, it is still part of our work to monitor the process and assist the team of developers with any problems that may arise. For example, although there may be things that are theoretically feasible, sometimes reality shows practical issues that we did not foresee on paper. Therefore, at this point, we must be prepared for potential changes and improvements. Even after the protocol has been implemented, we continue to monitor it and stay up to date with new research or changes to the technological landscape to make sure that it still works as intended and that its foundations are still solid..
In cryptography, when we say that a scheme is secure, what we really mean is that it is secure as long as certain conditions are met. Usually, these conditions are problems that we assume are difficult to solve. A scheme is secure as long as no one can solve the underlying problem. For this reason, it is very important that we stay up to date not only with new and better cryptographic primitives that come out every day but also ensure that our assumptions still hold. In this regard, we try to make our protocols as modular as possible so that if a piece becomes insecure we can quickly replace it.
Although the importance of the tasks we perform is usually clear from the outside, what our day-to-day work entails is often less evident. In fact, our routine changes quite a bit from day to day, especially depending on the project and the phase it is in. Generally, at the beginning of a project, we spend a lot of time understanding the motivation and the context of the problem we are trying to solve, thinking about the best way to approach it, and designing a scheme that fits the needs. This phase entails both individual and collective work, and it is essential to discuss together each other's suggestions until we reach a nearly solid proposal that can be written down on paper.
To test that what we are doing makes sense, our research must work hand in hand with security proofs. Typically, we first do an initial informal security check to see if the system seems to satisfy the requirements and properties we expected it to have and that no obvious attacks can be identified. If this is the case, we move on to the first development phase, where there are usually changes to our original proposal. When the scheme is in a more definitive shape, we move on to a formal security analysis. This last part usually takes quite some time but it is an essential part of our job, as it is the moment when we break down our protocol again and mathematically prove that no attack can exist under certain security assumptions. Without this thorough analysis, we cannot identify what can go wrong in our system and we run the risk of suffering attacks that were not evident in the initial analysis.
As a research team, we have worked on very different projects and the ones we are currently focused on are in different stages of development, which demonstrates the versatility of the team's work. On the one hand, Citadel is a recent proposal that is likely to become a self-sovereign identity solution for AML and KYC practices. We already developed a proof of concept of the protocol, and now we are working on integrating it into our testnet. On the security side, we documented the details of our transaction model and are now working towards its formal security analysis. Finally, we are finishing the design phase of Zedger, a decentralised asset model for securities. We recently had an intense work week where both developers and researchers met and discussed the proposal, and we are all very excited about the potential of this project.
Personally, what I like most about doing research at Dusk is that the problems we tackle come from a real need, and also that we experience the development of an idea from its incipient phase to the end. Unlike academic research, where researchers only see a small portion of this process, we get to contribute to the development phase and learn about the needs and particularities of what we do, such as the specific characteristics of the financial market and the regulations that apply to it.
