devcon 4 / reversing ethereum smart contracts to find out whats behind evm bytecode
Duration: 00:18:59
Speaker: Patrick Ventuzelo
Type: Talk
Expertise: Intermediate
Event: Devcon
Date: Invalid Date
Thinking Like an Auditor to Develop Safer Smart Contracts
Since 2017, ChainSecurity has audited countless smart contracts. Based on this experience, our experts will present a methodology for secure smart contract development. During the workshop, we will coach attendees to think about their project like an auditor would, to help them develop safer smart contracts using foundry and forked mainnet tests.
DigixGlobal’s security robustness and the Stablecoin, DGX
Talk on Contract Patterns and Security.
Smart Contract Security
After a quick overview of smart contract failures in the past, a list of important takeaways will be covered. Some coding techniques to prevent unexpected behaviour in smart contracts will be covered as well as some remarks about governance in decentralized systems.
Ethereum Security
Martin Swende gives their talk on Ethereum Security.
Evolution of Smart Contract Security in the Ethereum Ecosystem
A lot has changed in the smart contract development ecosystem in the year since DEVCON2. Our perspective as leaders of the smart contract security community OpenZeppelin shows us that the industry is maturing. We give a brief overview of how security patterns and practices have evolved in the past months, dive into some details of recent developments, and talk about promising projects and their plans for the future.
The Melon security approach
Melonport is striving to build a vibrant and successful developer ecosystem of Melon module builders. An important part of that ecosystem is the security and behaviour of smart contracts that make up Melon modules as well as how they interact with the Melon core and each other. In this presentation, we’ll demonstrate our ongoing technical efforts to assist Melon module developers in creating safe, secure smart contracts and touch on the importance of getting the auditing process right and how others can learn from our experience.
Vulnerability Coordination and Incident Response in a Decentralized World
There’s one question that every team of core blockchain developers has discussed at least once: what are we going to do when a critical vulnerability in our software is surfaced? By definition, everything we create is likely to include a vulnerability or code flaw and the difficult legal, ethical, and business issues arise when bugs show up in code. While decentralization does not require us to reinvent the first principles security, it does force us to challenge ourselves to manage significant complexity to reduce harm to those who depend on our code. This talk will discuss the CosmosCERT as a model for how teams can successfully coordinate vulnerabilities and respond to incidents in decentralized environments using on-chain governance mechanisms in a way that ensures stakeholders have a dedicated emergency response capabilities ready to go when the worst happens.
Batched Bonding Curves: Grieving DEX Frontrunners
It's been widely publicized that front-running is rampant across decentralized exchanges. Billy Rennekamp describes the technique developed to stop the parasitic behavior by using batched orders in tandem with bonding curves and how it's being used in a new fundraising app by Aragon Black.
(Defense Against) The Dark Arts - Contract Runtime Mutability
Smart contracts are no longer guaranteed to have immutable runtime code, and can be redeployed with new code using a variety of methods involving the CREATE2 and SELFDESTRUCT opcodes. In this presentation, we will investigate how this is done and how to protect against malicious mutable contracts. We will also explore ways these new techniques can be applied in order to enable new use-cases and to improve the user experience.
Fuzzing the Solidity Compiler
Since the Solidity programming language does not have a formal specification, testing the compiler implementation is an important way to obtain assurance about the correctness of code generated by the compiler. Fuzz testing is well-suited for this setting. However, applying fuzzing in the traditional manner (random input generation that is coverage-guided) is inefficient for testing compilers because a significant fraction of randomly generated code is syntactically invalid. If the fuzzer does not generate syntactically correct Solidity programs, the compiler will simply reject it. As a consequence, code optimization and generation subsystems of the compiler will not be tested. The approach adopted by us is to define a grammar for the Solidity programming language and automatically generate inputs based on this grammar. Grammar based fuzzing ensures that generated programs are successfully parsed by the front-end parser. We make use of libProtobuf and libProtobufMutator for defining the grammar and performing grammar-based mutations, and libFuzzer as the underlying fuzzing engine.