Our mission at Qredo as a self-custody protocol is to empower individuals and organizations with control over their own digital assets and data using secure and decentralized solutions.
We achieve this by using cutting-edge cryptography and blockchain technology to provide a secure and private platform for digital asset management, storage & deployment across the wider Web3 space.
We highly value privacy, security, and decentralization, and we believe that individuals and organizations should have direct control over their digital assets without relying on third-party intermediaries or having to trust centralized authorities or other custodians.
We also place a strong emphasis on developing innovative and secure technologies to meet the evolving needs of our users. This is where Qredo Labs comes in.
Qredo Labs is an open source research & product development laboratory. We think a safe internet is worth fighting for, and we do our part by building turnkey protocol products that can fundamentally improve Qredo Network.
The team at Qredo Labs are a community of blockchain innovators, tech-obsessed computer scientists, resolute security architects and crafty cryptography mathematicians. We're passionate about freedom & security and committed to open source as the route to transparency and trustlessness.
We investigate, discuss, and peer review scientific advances in different technological fields, contribute to the security of open source developments and, via Qredo's product releases, to the overall security of the wider blockchain ecosystem.
Qredo Labs is actively researching several fascinating emergent technologies, including those utilizing zero-knowledge proofs (ZKP). ZKPs are a very interesting area of cryptography which you can read more about in our recent article, Qredo 101s: Just What Exactly Is a Zero-Knowledge Proof?
Zero-knowledge (ZK) is a type of cryptographic proof that allows one party to prove to another that they know a secret value without revealing the secret itself.
This technology is very aligned with Qredo Labs' values as a decentralized self-custody protocol and platform that prioritizes verifiability, trustlessness, and transparency.
The team's research on topics such as ZK and their dedication to contributing to the wider open source community demonstrates Qredo Labs' commitment to advancing the field and building a more secure and decentralized future.
We have been exploring the use of ZKPs to design systems where a party can convince others that some computation was carried out correctly, eliminating the need to trust a counterparty claim about the results of the computation.
In such a context, the proof shows that executing a given program on some public inputs (that the verifiers know about) and some private inputs (that only the prover has access to) does indeed yield the result claimed by the prover.
Depending on the use case, private inputs may be sensitive data, but they might also consist of certain information or states which are only available where the prover lives, which can potentially help it perform the computation more efficiently.
There are many approaches to producing zero-knowledge proofs of computation, and we have been experimenting along several distinct lines of development. All these techniques require transforming the computation into a stronger mathematical form, encoding the operations to be performed using algebra over finite fields.
When executing the programs in this form, the ZKP system takes note of all the intermediate results of the computation to prove and emit constraints stating that these results were obtained when running all the corresponding operations.
Those constraints are usually expressed as equations over a finite field and are finally compressed using clever techniques that typically involve polynomials and some cryptographic tools (elliptic curves, collision-resistant hash functions) over the finite field. The cryptographic tools also participate in establishing the "zero-knowledge" property of ZKPs, not divulgating any of the private inputs that the prover has used to run its computation.
The main differences between the various ZK proof systems reside in how the computation is represented, how constraints are generated from running the computation, and the flavour of cryptographic tools used to go from the executed computation to some form of commitment about the integrity of the computation's result, that a verifier can check.
This commitment is what constitutes the proof, which is then typically stored or sent around for verification. The size of the proof as well as the time it takes to produce or verify it, all depend on the ZK protocol used.
Some require a so-called trusted setup, which is a ceremony that involves various parties of your system and that takes place before you can produce or check any proof. This typically allows the production of very small proofs that are also very quick to verify (SNARKs, PLONK and others).
Others do not require such a step but produce larger proofs (most notably STARKS).
More recent efforts mix and match these approaches to avoid trusted setups but still produce rather small proofs (e.g., Plonky2). What these all have in common is that verifying a proof is always less work than redoing a computation.
We have been experimenting with a few of those proof systems, with an emphasis on STARKs and Plonky2-style systems, which reuse some aspects of STARKs. The reason for this emphasis is that the computations we are proving are large, with fairly repetitive structures to them (think for/while loops, and repeated calls to a couple of key functions).
For all the systems from the SNARK family, this amounts to copying and pasting the repeated computation as many times as it is executed, while the STARK-style approaches do not suffer from this problem and handle such scenarios much more efficiently.
Another remarkably interesting aspect of many of those ZKP systems is that they allow for recursive verification of proofs: as part of the computation that we want to generate a proof for, we can verify a previously generated proof!
The resulting proof for this larger computation, therefore, not only states that we performed all the computations correctly, but also that whatever that earlier proof was stating, is also included in this larger proof.
What this means for applications built around ZKPs is that we do not necessarily have to generate a proof for an exceptionally large computation in one go. We can incrementally build up proofs that encompass larger and larger chunks of computations, or we can divide up the computations into chunks that can be proved in parallel, and recursively verify all those smaller proofs to produce the final one that will carry a statement about the integrity of the whole computation.
This last technique is at the heart of systems like Plonky2, zkTree and others. One can, for example, emit a STARK proof and verify it from within a SNARK-like ZK system, so as to get the benefits of STARKs while producing a very small proof at the end of the process, which can then be stored within a block.
The large computations that we want to prove, however, are not only challenging because of their sheer size, but also because some common operations are very cumbersome to handle for most of the ZK systems.
A prime example of such operations can be seen with bitwise AND, OR, and XOR, heavily used in hashing functions like SHA or Keccak, which are quite common in our ecosystem. Since the program logic is represented in terms of operations over elements of a finite field (typically integers modulo a prime number), ZKP systems must express constraints over the individual bits of field elements, because those bitwise operations are not part of the finite field algebra vocabulary.
Some ZK systems provide special mechanisms for dealing with such operations somewhat more efficiently, like Miden VM's bitwise chiplets or Polygon Hermez's Keccak hashing framework.
Alternative approaches that tackle the problem at the mathematical level also exist, such as BooLigero, which works in a bitwise operation-friendly field, with integers modulo 2 (0 or 1, i.e., bits) as the primary component.
A potential solution could consist in being able to express subsets of the computations in such a system and have a verifier for those "sub-proofs" live in the normal field, analogous to how STARK proofs can be verified within a SNARK-like system.
If you'd like to read more in-depth material on ZKP systems and the software and mathematics mentioned, we've assembled some excellent resources for your further reading below.
Zero-knowledge proofs of computations are certainly proving to be fascinating and powerful building blocks for trustless, decentralized systems. At Qredo, we look forward to publishing more about our ongoing ZK projects, so stay tuned!
We welcome developers with an active interest in this area of cryptography to get in touch with us at Qredo. We strongly believe in community-led development and look forward to connecting with more amazing developers in the wider blockchain ecosystem.
As we continue to explore and experiment with zero-knowledge proofs (ZKPs) at Qredo Labs, we invite you to join the Qredo Discord community to share your thoughts, ideas, and questions about ZKPs and other cutting-edge cryptographic technologies. We have now opened a new channel on our Discord specifically for zero-knowledge proofs, and we hope to see you there. You can also reach out to us directly right here if you prefer!