Cryptography in Decentralized Protocols
After few years into this emerging, yet fast-moving blockchain space, it became apparent that knowledge in cryptography is indispensable. In this context, knowledge refers to: 1) what, where, and why cryptography is used; and 2) limitations of the cryptography used in decentralized protocols.
The need to understand the what, where, and why
Independent to what geopolitical, economic, organizational or akin forces that impact the speed at which research in cryptography advances, the technology in elder industries that leverages the latter is perceived to progress at a significantly slower pace. Nonetheless, the application of relatively novel cryptography in this space is remarkably common —and likely to become even more vital overtime. Prevalent examples are zk-SNARKs, in ZCash or recursive SNARKs in Coda protocol. The former leverages research that is a few decades old to enhance anonymity or privacy in payment systems, whereas the latter is notable for its fresh application to enable computational compression. Simultaneously, we witness the adoption of contemporary research as potential solutions to distinct problems in the space, such as threshold digital signature algorithms, noteworthily the research in threshold ECDSA being conducted by KZen.
Whilst it is exhilarating to spectate and speculate how the intersection between cryptography and blockchains could capriciously shape the future, keeping track of it —as bystanders or protagonists— often requires a significant commitment of scarce resources, such as time, which is not plentiful for most participants.
The need to understand the limitations
It is unfortunate to observe how often decentralized protocols are described through absolute adjectives. While human language and communication hardships are out of scope, statements such as Bitcoin is secure or ZCash is private and Monero is not private can be harmfully misleading: the usage of cryptography, be it ripe or novel cryptographic algorithms, does not guarantee that a system magically obtains the properties of security, privacy, or scalability.
Albeit cryptographic tools can provide unique properties or features to decentralized systems, they often come with constraints or limitations, forcing protocol designers and engineers to make trade-offs and fueling their drive to continuously seek for improvements. Knowing what limitations cryptographic protocols present is crucial for all participants to understand implications, make informed decisions, and mitigate risks when working on or interacting with decentralized protocols.
What to expect from these articles
This piece marks the introduction to a series of writings that explore what, where, and why cryptographic tools are used in decentralized protocols, and what theoretical and practical limitations they present. The goal is to make specialized knowledge — which to some can be intimidating and overwhelming– more accessible to a diverse community.
Simply put, readers should be able to participate in discourse with less absolute and more constructive statements, such as: “Bitcoin is more secure than currencies issued by centralized parties because of a, b, c”; or “ZCash is more private than Bitcoin because it leverages zk-SNARKs which enable x, y, z”, or “Monero was less private than ZCash because it used to rely on ring signatures, which present limitations d, e, f”.
Upcoming articles (subject to change)
- Cryptography in Proof-of-Work systems
- Cryptography in Privacy-preserving Proof-of-Work systems
- Cryptography in Proof-of-Stake systems
Written by Awa Sun Yin, founder of Metastate.
Metastate has ceased its activities on the 31st of January 2021. The team members have joined a new company and working on a new project. If you're interested in zero-knowledge cryptography and cutting-edge cryptographic protocols engineering positions in Rust, check out the open positions at Heliax.
If you have any feedback or questions on this article, please do not hesitate to contact us: hello@heliax.dev.