On December 12, over 150 attendees joined a special, half-day Empire Hacking to learn about pitfalls in smart contract security and how to avoid them. Thank you to everyone who came, to our superb speakers, and to BuzzFeed for hosting this meetup at their office.
Watch the presentations again
It’s hard to find such rich collections of practical knowledge about securing Ethereum on the internet. For many of you, it was even harder to attend the event. That’s why we’re posting these recordings. We hope you find them useful.
Anatomy of an unsafe smart contract programming language
- Solidity harbors many unsafe features that allow even experienced, competent programmers to easily shoot themselves in the foot.
- Solidity is changing quickly, which is both bad and good. Developers must keep pace with new compiler releases and beware the implications of contract upgradability.
- There is an effort to introduce an intermediate representation to the compiler. Early indications suggest that it suffers from many of the same design decisions that have plagued Solidity.
Evaluating digital asset security fundamentals
- The supply chain is untrustworthy. How do you validate that an asset issuer’s node, smart contract, or wallet code is authentic?
- Security communications channels are immature. If you find a bug, how do you know where to report it? Conversely, how can exchanges like Coinbase become aware if a bug is found? Monitoring a Telegram chat for each asset does not scale.
[For the time being, use our directory of Blockchain Security Contacts.]
- How do we know when a smart contract owner is malicious? The code itself may be secure, but the owner’s key is a single point of failure. If compromised, it can arbitrarily modify the accounting of an asset in most cases.
Contract upgrade risks and recommendations
Our own Josselin Feist compared several different strategies for upgrading smart contracts. This talk covers everything you need to know to decide how and if to implement upgradability in your contracts (slides).
- Upgradability is useful for developers as it allows for features to be added and bugs to be fixed after the fact. However, it also adds complexity and increases the likelihood of deployment mistakes.
- Use the simplest upgrade system that suits your needs. Compared to data separation, the delegatecall proxy pattern is very fragile and adds even more complexity.
- Instead of these upgradability patterns, consider contract migration. Migration is more involved, but it allows for recovery from many more scenarios.
How to buidl an enterprise-grade mainnet Ethereum client
S. Matthew English of PegaSys highlighted the trials and tribulations of implementing a new Ethereum client. Many of the insights in the talk apply just as well to any large-scale software engineering projects.
- Building an Ethereum client is hard. The protocol itself is poorly documented, uses non-standard computer science concepts, and has continued to evolve at the same time as existing clients evolve.
- Team communication, architectural design, and incremental progress validation were important factors in the successful development of PegaSys.
- Pantheon is now syncing with Ethereum mainnet, has been open-sourced, and is available for download.
Failures in on-chain privacy
- Privacy in cryptocurrency has been misunderstood since the very beginning. It’s important that we figure it out now before it’s too late to fix.
- Decoy-based approaches may seem successful in isolation, but the privacy claims they make break down in real-world scenarios.
- Stronger approaches are deployed and efficient, but they still need important work to improve usability for end users.
Secure micropayment protocols
- Micropayments are useful for a variety of applications, in particular those with the potential for ongoing or a high volume of transactions. However, high deployment and transaction costs have stymied widespread adoption.
- Security considerations for clients common to most micropayment methods include security of the hot signing key and timely transaction confirmation of additional necessary transactions, even when gas prices fluctuate.
- Important considerations for probabilistic micropayments include secure random number generation and protection from replay attacks and double spends.
Designing the Gemini dollar: a regulated, upgradeable, transparent stablecoin
- Upgradability in smart contracts provides a means for response to illicit activities and bugs, but can reduce transparency and expand the attack surface.
- Contract modularity, ownership distribution, and “time-locked” upgrades help mitigate these issues.
- Take every opportunity to provide multi-level mitigations. Gemini ensures that even if an attacker were to compromise a contract with all of its underlying logic (Impl), its custodian/owner-contract would need to be compromised too, as it is the sole entity to confirm printed tokens.
Property testing with Echidna and Manticore for secure smart contracts
- Unit Testing is not always sufficient: it tests one individual case at a time, and typically focuses on known cases and failure modes. Property Testing aims to cover unknown cases by specifying generic code invariants.
- Echidna is a tool for property testing smart contracts, which is extremely fast and can discover new transaction sequences that violate code properties.
- When property-based testing with such tools, you’re sure to hit some conditions that a user might have typically missed in their individual unit tests.
Simple is hard: Making your awesome security thing usable
- A great idea or tool can often be derailed by its (lack of) usability, undermining its potential to deliver immense real-world value. Sweat the “boring stuff” if you want your worthwhile work to be worth it.
- Most end users don’t change settings or look for anything beyond the default, most devs don’t want to mess with complex configs. Practice simplicity at every opportunity and do as much as you can in the background for both.
- Regular people care about simplicity, stability and cost. Power users care about implementation details. Developers care about approachability, utility, and ops overhead. Businesses care about technical risk and the bottom line. Put yourself in the shoes of each; don’t expect them to change priorities just because you made something innovative or pure.
- Practice what you preach; if we (in the security and “crypto” communities) use tools that are fundamentally insecure or data hungry, how can we expect others to act differently?