탈중앙화 금융 보안의 스마트 컨트랙트 감사 이해

### 스마트 컨트랙트 감사 마스터하기: 아레나 경쟁사를 위한 최고의 코드에서 얻은 인사이트
* 💻 C4 디스코드 채널에 참여하거나 **trustindistrust.com을 방문**하면 스마트 컨트랙트 감사에 대한 유용한 리소스와 토론에 참여할 수 있습니다.
* 🔍 코드에 들어가기 전에 **프로토콜의 기본 사항과 개념적 작동 방식**을 이해하는 것은 취약점을 식별하기 위한 탄탄한 토대를 마련하는 데 매우 중요합니다.
* 🛠 "개발자가 구축하는 시스템에 대한 개발자의 이해에는 항상 어느 정도 차이가 있기 때문에" **개발자가 버그로 이어질 수 있는 가정을 발견하기 위해서는 코드를 철저히 검토**해야 합니다.
* ⚙ 프로젝트의 새롭고 새로운 측면과 재입력 오류와 같은 일반적인 실수에 초점을 맞추면 감사자가 즉시 보이지 않을 수 있는 **중요한 취약점**을 식별하는 데 도움이 될 수 있습니다.
* 📚 기존 은행 시스템에서는 이러한 원칙 중 많은 부분이 추상화되어 있기 때문에 **탈중앙화 금융 프로토콜과 금융 개념의 기본**을 숙지하는 것은 필수입니다.
* 💡 하드햇, 파운드리, 텐더리와 같은 도구를 활용하면 감사 프로세스를 간소화하여 **스마트 컨트랙트를 효과적으로 테스트하고 디버깅**할 수 있습니다.
* 🏆 코드 포 아레나의 경쟁적인 성격은 독립 연구자들에게 상당한 보상을 받을 수 있는 기회를 제공하며, **한 최고 수익자는 취약점 식별을 통해 90일 동안 67,000달러 이상의 수익**을 올렸습니다.
* 🔑 마지막으로, 감사 대상의 범위를 이해하는 것이 중요한데, 이 범위를 벗어나는 발견은 보상을 받을 수 없으므로 **감사 시 전략적 집중의 중요성**을 강조합니다.

프로토콜의 아키텍처를 이해하는 것은 탈중앙 금융 프로젝트의 효과적인 보안 감사를 위해 매우 중요합니다.

this is ore AKA trust underscore 90 on Twitter, and this is or being the top earner four times in a row on code for Arena's security audits. Landing him the number one spot in the past 90 days in the leaderboard and totaling over 67 thousand dollars. And actually before that also like a couple of other contests, a total about like 110 and 115k code free in this platform where instead of going to a traditional auditor to get your code reviewed, you actually open it up to Independent researchers to compete to find the most amount of vulnerabilities. And those who find the most and the most novel vulnerabilities get paid. And Trust has been killing it, and I wanted to find out how he was able to do this. So I invited him to an interview to learn more about his process in finding these bugs. So I started by understanding first of all the fundamentals before even starting to deal with security concept because security can only be built first on like good foundational understanding of the technology. Step one understand the

basics. Now, this is both the basics of EVM and Solidity and smart contracts, but also the basics of the whole space and the protocols that you're going to be working with. There were a lot, like obviously, there's a lot of knowledge gaps in terms of DeFi protocols and financial concepts that most people aren't aware of because eventually this is how the banking system works currently, but it's really abstracted away from us in the form of a bank account, which does all these things and institutional services. And in DeFi, everything happens transparently. There's a couple of weeks where you just learn about how collateral ratio works and how liquidations work, and I actually really enjoyed getting up to speed on all these concepts in Web 3. For Solidity, the best reference was the actual Solidity website. So then I asked, What's the first thing you do when you start auditing a project in code for Arena? To that, he gave us step two, which is understand the architecture of the protocol you're working with. Not

just the code but the actual project. I like to take a top-down approach, and through this approach, I will start by having a sound understanding of what the contract's external surface looks like. All right, so as a user, what are you allowed to do with this contract? And also, read all the docs because they may give you pretty cool understanding that you wouldn't have otherwise. So, the docs are basically preparation for diving into the code. I start from a zoom-out view and start digging into places where I think it could be more interesting to look at and encode Arena and audits in general. There's scope, so you want to make sure you spend your time on the code that isn't the code that is in scope in code for Arena and most security audits. There's this concept called scope. It's what you're allowed to look at and what you're not allowed to look at. If you submit a finding, a critical vulnerability for something that's out of scope, you don't get paid. Once you identify all these areas of code, you start filtering out

the trivial things, and you want to focus on the more complex stuff, like what sort of code is actually new or novel in this particular project, right? I like to spend my time focusing on the new stuff in each project, and also if they've changed something on top of another project, they need to ask yourself, like, why did they change it, and have they not fixed any issues that exist in the original? Like, in the fork project, there is basically no shortcut to understanding how the code actually works, and in order to find bugs, you need to find any assumptions that the developers are making which are not definitely true, because if there is no gap, there's no misunderstanding that the developer did, then there won't be bugs in the contract. There's always going to be some gap in a developer's understanding of the systems they're building. That's one way to focus. Another way to focus is on easy mistakes that keep on being made, re-entrances or precision loss errors, lots of these common mistakes that we keep happening.

keep seeing so you can have a pretty. You can take a wide view of all the projects, like what the product is doing, and see if there's any of the simple things going on wrong. But usually, these bugs will get reported by a lot of others. They're in the submissions that really make you the big bucks, are going to be like the special ones that require the most theological understanding of the project. And that's usually the ones that actually take you the longest time to find because on the surface level, they aren't even visible. And sometimes, these bugs aren't even to do with anything about solidity. It's only about the thought process. It's about what are you logically allowed to do and it's not. It could have been written in English and the bug would still be there. This is like some of the more elegant findings you can find, right? So if you read the docs, you say, Hey, this is an application for staking. You're saying once you get that, once you understand what staking is, locking up collateral, then you can go to

the docs and say okay where's the stake function okay it's here is it doing is it match up with what I conceptually think they're trying to do and then you just keep doing that for the whole contract yeah and eventually you want to go over the whole contract at least as a first pass and sometimes they even document the number of passes they do per Amtrak in order to increase my confidence that this part is legit you definitely want to go over everything separately and then after that you also want to have another pass where you try to understand the dependencies and the ways in which to the different contracts interact together because that may introduce lots of risks as well so what are the tools tools that you'd use to do this obviously it's important to have a setup where you can experiment and try out ideas PLC my setup is like a Windows machine with an Ubuntu WSL too and I use it to run all my hard hat and Foundry tests I usually try to do it as little

as possible on the Windows side, and because everything works a little more smoothly on Linux, a lot of my testing is on Remix because it's just really great to trace through and check out a lot of different tests quickly. And when I need to check specific events that take place in some blockchains, I'll use Tenderly. Tenderly.co was a really great tool for debugging specific transactions and trying to deploy your own contracts and see how they behave. I try to use the different tools as the most important and appropriate tools for the specific circumstances. It's important to know Foundry, Hardhat, and for Code Arena contests, we want to make use of the existing test suite that each project provides because it cuts down on the amount of prep time you need. And it's also great for developers as they're like to validate whatever finding you bring with their own tests, with their own tests. So, it's easy for them to get into it and understand exactly what you're doing. Or where can people find you? Find me on Twitter, on Trust for

90 also will be available. I hang around in the C4 Discord Channel a lot and on the unified channel, so you can find me over there and also on my website, trustindistrust.com. So, there it is. Understand the fundamentals, understand exactly what the protocol does from a conceptual level, and then number three, comb through the code, seeing if what it should do is what it is doing. Looking forward to seeing you all competing in Code for Arena. [Music] foreign foreign [Music]

How to become the #1 Auditor in Web3

Patrick Collins

코드 포 아레나의 보안 감사에서 Trust의 성공 사례

트위터에서 trust_90이라고도 알려진 Trust는 지난 90일 동안 67,000달러 이상의 수익을 올리며 Code for Arena의 보안 감사 부문에서 최고 수익을 올렸습니다.

그의 성공은 코드를 철저히 검토하고 종속성을 이해하며 프로세스를 문서화하는 독특한 접근 방식에 기인합니다.

Trust는 테스트를 위해 Ubuntu WSL이 설치된 Windows 머신을 사용하고, 아이디어를 실험하고 시도하기 위해 하드햇과 파운드리를 실행합니다.

계약을 이해하기 위한 하향식 접근 방식

저자는 컨트랙트의 외부 표면과 사용자 권한을 이해하는 것이 중요하다고 강조합니다.

코드에 들어가기 전에 문서를 읽는 것은 인사이트를 얻는 데 매우 중요합니다.

범위의 개념은 감사가 허용되는 코드 영역을 정의하며, 범위 밖에서 발견된 중요한 취약점은 지불 대상이 되지 않으므로 강조됩니다.

프로젝트 감사에서 버그 이해하기

프로젝트의 버그는 처음에는 눈에 띄지 않는 경우가 많지만 대개 다른 사람들이 보고하기 때문에 찾기가 어려울 수 있습니다.

이러한 버그는 코드 자체보다는 프로젝트 설계의 논리적 사고 과정과 관련이 있을 수 있습니다.

스테이킹과 담보와 같은 프로젝트의 기본 사항에 대해 배우는 것은 탈중앙 금융 프로토콜의 일반적인 지식 격차를 이해하는 데 매우 중요합니다.

블록체인 개발을 위한 테스트 및 디버깅 도구

원활한 작동과 빠른 이벤트 추적으로 인해 테스트에 Remix를 선호합니다.

특정 트랜잭션을 디버깅하고 컨트랙트를 배포하는 데는 Tenderly.

발표자는 준비 시간을 절약하고 개발자의 검증을 용이하게 하기 위해 코드 아레나 대회에 프로젝트에서 제공하는 테스트 스위트를 사용하는 것이 중요하다고 강조합니다.

이 강연자는 C4 디스코드 채널과 웹사이트 trustindistrust.

이들은 프로토콜의 기본 사항과 코드의 기능을 이해하는 것이 중요하다고 강조합니다.

새로운 코드, 프로젝트 변경 사항, 개발자가 흔히 저지르는 실수를 집중적으로 분석하여 잠재적인 버그를 파악합니다.