Mistake # 2 – Craving for Recording
Privacy tools should exhaust every means to ensure non-retention of user activities, especially personally identifiable information such as IP addresses and browsing history.
Privacy protocols ought to be crafted with an all-encompassing ethos that refrains from exploiting a lapse in judgment to de-anonymize users.
For instance, Railway Wallet (which integrates RAILGUN privacy technology) defaults to proxying RPC calls for all users, ensuring that even in the absence of a VPN (which users should ideally employ 🙁), their IP remains undisclosed to RPC nodes.
Mistake # 3 – Encrypted Condition
Why not maintain absolute privacy throughout the entire system? The proposition is tempting… but having a completely encrypted condition is as undesirable, in certain respects, as being entirely public.
Maintaining an encrypted state creates an opaque environment where neither users nor observers comprehend the actions of the decentralized application (dApp). This nullifies one of the most significant security aspects of blockchains: public verifiability.
If the dApp operates in secrecy, how does one verify the accuracy of economic transactions and actors? How does one respond effectively to an exploitation or malicious endeavor if occurrences remain undetected?
User privacy is indeed beneficial – as is protocol transparency.
Mistake # 4 – Reliance on Specific Producers
Being “trustless” obviates the need to rely on a third party (e.g., a corporation, agent, or bank clerk) to ensure the functionality of a protocol. The strength of zero-knowledge encryption lies in its reduction of dependencies, including those on producers.
Consider, for instance, constructing a privacy system dependent on Software Guard Extensions integrated by Intel into their CPUs. The security of such a system hinges on a potential single point of failure – the trust placed in Intel’s correct implementation of its product.
While Intel’s incentives align with proper conduct, reliance on SGX perpetuates a persistent vulnerability and unwarranted presumption of trust. Moreover, there are gatekeeping implications, as SGX necessitates specialized, relatively costly, obscure, and challenging-to-maintain hardware – in contrast to a proof-of-stake validator that can be operated on a Raspberry Pi.
Mistake # 5 – Going Maverick
Cryptographic privacy presents an enticing narrative, yet it does not alone justify constructing an entirely new blockchain or rollup (unless the specialized chain introduces a distinct technical innovation).
Privacy systems wield the greatest impact when available on chains where users and financial transactions are prevalent. For better or worse, decentralized finance (DeFi) has coalesced around Ethereum, EVM, and a handful of other environments like Solana. Solidity reigns supreme and has consequently benefited from extensive security research.
Initiating a new execution environment and enticing developers and users requires time and often unsustainable incentives. Meanwhile, billions of dollars in value are already deposited on public chains, desperately necessitating privacy measures.
Dedicated privacy chains also raise additional security concerns, such as the need for bridges – widely acknowledged as the least secure component of blockchain networks. Other apprehensions include the centralization of consensus, validation, and sequencers.
Mistake # 6 – Complexity in Construction
Developers are often revered as prodigies (and some indeed are). However, cryptography poses sufficient challenges that imposing proprietary languages, toolchains, or ecosystems on builders is gratuitously complex and counterproductive.
Contracts scripted in languages like Solidity or Vyper are interoperable among networks supporting EVM. This is not the case for Rust and other WebAssembly chains. Each network possesses its own runtime standards. From a builder’s perspective, this necessitates the maintenance of separate contract codebases for each chain, despite employing the same language.
Consequently, the product becomes less accessible.
Mistake # 7 – Nascent Technology
“Magic Internet Money” is an amusing meme. Nonetheless, crypto developers are crafting financial technology with real-world ramifications, handling actual funds.
Privacy technology bears the dual responsibility of factoring in the “realness of money” and ensuring “privacy” itself – i.e., it must withstand financial exploits and any potential deanonymization attempts. The extensive corpus of existing academic research on the technology exists for a reason.
Unless you wish to emulate IOTA’s fate, it is prudent to abide by the age-old adage “never roll your cryptography.”
Privacy technology, in particular, should be subjected to rigorous testing and meticulous deliberation, including extensive audits by security firms, evaluations by privacy proponents, and penetration testing by ethical hackers.
Otherwise, how can one expect individuals – especially the anticipated influx of mainstream users – to stake their identity and finances on a complex technological platform?
Conclusion
Communal blockchains are inherently predisposed towards exposure. Incorporating on-chain privacy systems while preserving the original rationale for adopting crypto, such as verifiability and decentralization, poses a formidable challenge.
A valuable resource for assessing the privacy efficacy of your chosen privacy tool is the Web3 Privacy Now initiative, which has categorized and evaluated various cryptographic privacy tools. Consult it as an excellent initial stride towards safeguarding your online identity and financial assets.
