스마트 계약이란 무엇인가?

이더리움에는 일반적으로 두 가지 유형의 계정이 있습니다: 외부 소유 계정(EOA)과 스마트 계약 계정(SCA)입니다.

EOA는 우리가 일반적으로 자금을 저장하고 애플리케이션과 상호 작용하는 데 사용하는 전자 금융 계정과 매우 유사합니다. 예를 들어, 사용자들은 PayPal을 통해 법정 화폐를 입금하고 다양한 웹사이트, 상점, 앱과 상호 작용하여 결제를 합니다. DeFi 채굴자들은 보통 자신의 EOA에 암호화폐를 저장하고, DeFi dApp과 상호 작용하며, 수익을 위해 dApp에 자금을 예치합니다. 그러나 EOA에는 전자 금융 계정이 가지고 있지 않은 특징이 있습니다: 사용자들은 개인 키의 소유권을 통해 EOA에 대한 통제권을 검증받아야 합니다 - 당신의 키가 아니면, 당신의 코인도 아닙니다.

SCA 또한 기본적으로 실행 가능한 바이트코드 세그먼트(스마트 계약이라고도 함)와 연관된 계정의 한 유형입니다. 스마트 계약은 다양한 비즈니스 로직을 설명하고 dApp의 백엔드 역할을 합니다. 그러나 전통적인 튜링 완전 개발 언어에 비해 더 많은 제약이 있음에도 불구하고, 준 튜링 완전 스마트 계약은 여전히 수많은 공격에 취약했으며, 블록체인 산업에 셀 수 없는 타격을 주었습니다.

일반적인 스마트 계약 공격

1. 재진입 공격

가장 흔하고 악명 높은 공격은 재진입 공격으로, 이는 이더리움 클래식의 생성으로 이어진 이더리움 포크의 원인이 되었습니다. 2016년, 해커들은 The DAO 계약에 대해 재진입 공격을 실행하여 당시 1억 5천만 달러 이상의 가치가 있는 3,600,000 ETH를 훔쳤습니다. 이더리움의 초기 단계에서 발생한 이 공격은 생태계를 황폐화시키고 투자자들의 신뢰를 무너뜨렸으며, 결국 포크로 이어졌습니다.

구체적인 로직

재진입 공격의 원리를 더 잘 이해할 수 있도록 예를 들어 설명하겠습니다. B 은행이 이전에 A 은행에 돈을 빌려주었습니다. 어느 날, B 은행이 A 은행에 송금을 시작하여 모든 돈을 B 은행으로 다시 송금해 달라고 요청합니다. 정상적인 경로는 다음과 같습니다:

1단계: B 은행이 자금 인출을 요청합니다

2단계: A 은행이 B 은행으로 자금을 송금합니다

3단계: A 은행이 B 은행으로의 송금 성공을 확인합니다

4단계: A 은행이 B 은행의 계좌 잔액을 업데이트합니다.

그러나 B 은행이 2단계 이후에 허점을 만들고 3단계에서의 확인 없이 계속해서 A 은행에 모든 돈을 요청한다면, B 은행에 있는 A 은행의 계좌 잔액은 변경되지 않은 채로 남게 됩니다. 이러한 재귀적 호출은 A 은행의 모든 자산을 고갈시킬 것입니다.

관련 스마트 계약

A 은행의 계약은 두 가지 기능을 포함합니다:

deposit(): A 은행에 돈을 입금하고 사용자의 잔액을 업데이트하는 입금 기능;
withdraw(): 사용자가 A 은행에서 모든 자금을 인출할 수 있게 하는 출금 기능.

B 은행의 공격 계약은 주로 receive() 콜백 함수를 트리거하는 루프를 포함하며, 이는 차례로 Bank 계약의 withdraw() 함수를 호출하여 1회 입금, 1회 출금, 그리고 receive() 콜백 함수 호출의 순서를 통해 A 은행의 자산을 고갈시키고, 최종적으로 A에 있는 B의 잔액을 업데이트합니다. 여기에는 두 가지 기능이 포함됩니다:receive(): ETH를 받을 때 트리거되는 콜백 함수로, Bank 계약의 withdraw() 함수를 재귀적으로 호출하여 출금을 합니다.
attack(): 먼저 Bank 계약의 deposit() 함수를 호출하여 잔액을 갱신한 다음 withdraw() 함수를 호출하여 첫 번째 출금을 시작하고, receive() 콜백 함수를 트리거하여 withdraw()를 재귀적으로 호출하여 Bank 계약의 자산을 고갈시킵니다.

해결책

재진입 잠금 구현

재진입 잠금은 재진입을 방지하기 위해 사용되는 수정자로, 호출이 실행을 완료해야만 다시 호출될 수 있도록 보장합니다. 예를 들어, Bank B의 공격이 Bank 계약의 withdraw() 함수를 여러 번 호출해야 하므로, 재진입 잠금을 구현하면 이 공격은 실패하게 됩니다.

사용 방법

2. tx.origin의 잘못된 사용

스마트 계약에서 tx.origin의 주요 기능은 거래를 시작한 원래 계정을 검색하는 것입니다. 여기서는 스마트 계약의 두 가지 일반적인 변수인 msg.sender와 tx.origin에 대해 논의하겠습니다. msg.sender는 스마트 계약을 직접 호출하는 계정을 검색하는 반면, 블록체인 세계에서는 다양한 스마트 계약의 중첩 및 상호 호출(예: DeFi Lego) 때문에 tx.origin이 거래를 시작한 원래 계정을 얻는 데 필요합니다. dApp 개발자가 코드에서 tx.origin의 보안만 확인하고 공격자가 중간 계약을 배포하여 tx.origin을 우회하고 공격을 시작하는 보안 검증을 무시할 때 취약점이 발생합니다.

구체적인 로직

여기 일반적인 공격 시나리오를 깊이 이해할 수 있는 예시가 있습니다. Bill은 Bill이 이체의 시작자인지 확인하는 스마트 지갑을 가지고 있습니다. 한번은 Bill이 피싱 웹사이트에서 NFT를 발행했습니다. 이로 인해 웹사이트는 Bill의 신원을 얻고 그의 신원을 사용하여 스마트 지갑에서 이체를 시작할 수 있게 되어 자산 손실이 발생했습니다. 일반적인 상황에서는 사용자가 이러한 함정에 빠질 가능성이 적지만, 지갑을 사용하여 dApp과 상호 작용할 때 상호 작용 프롬프트를 확인하는 것을 자주 잊어버립니다. 예를 들어, 둘 다 Mint() 함수와 관련된 경우 부주의한 사용자는 쉽게 피싱 함정에 빠질 수 있습니다. 피싱 웹사이트 내의 비즈니스 로직은 함정으로 가득 차 있으므로 일반적인 상호 작용 중에 상호 작용 프롬프트에 오류가 있는지 확인하는 것이 중요합니다.

스마트 지갑 계약

스마트 지갑 계약에는 하나의 함수가 포함되어 있습니다:

transfer(): 지갑 소유자만 시작할 수 있는 출금 함수로, 이 경우 Bill입니다.

피싱 공격 계약

피싱 공격 계약에서 Mint() 함수는 사용자가 해커의 주소로 자금을 전송하도록 유도합니다. 이 함수는 다음과 같은 기능을 포함합니다:

Mint(): 호출되면 피싱 함수는 내부적으로 Wallet 계약의 transfer() 함수를 실행합니다. 원래 시작자가 사용자 자신(이 예에서는 Bill)이기 때문에, verification require(tx.origin == owner, "Not owner") 검증은 문제가 되지 않습니다. 그러나 전송 대상 주소가 이미 해커의 주소로 변조되어 있어 자금 도난이 발생합니다.

해결책

1. tx.origin 대신 msg.sender 사용

계약 호출이 여러 번 involved되더라도(계약 A → 계약 B →…→ 대상 계약) msg.sender, 즉 직접 호출자만 검증하여 악의적인 중간 계약으로 인한 공격을 방지합니다.

2. tx.origin == msg.sender 검증

이 방법은 악의적인 계약을 멀리할 수 있지만, 개발자는 모든 다른 외부 계약 호출을 효과적으로 격리하므로 자신의 비즈니스 현실을 고려해야 합니다.

3. 난수 생성기(RNG) 공격

이는 2018년과 2019년경의 도박이나 베팅 dApp 트렌드로 거슬러 올라갑니다. 일반적으로 개발자들은 스마트 계약에서 특정 시드를 사용하여 추첨 과정에서 당첨자를 선택하기 위한 난수를 생성합니다. 흔한 시드로는 block.number, block.timestamp, blockhash, keccak256 등이 있습니다. 그러나 채굴자들이 이러한 시드를 완전히 통제할 수 있어, 일부 경우에는 악의적인 채굴자들이 이익을 얻기 위해 변수를 조작할 수 있습니다.

일반적인 주사위 계약

주사위 계약은 다음과 같은 한 가지 기능을 포함합니다:

Bet(): 사용자가 베팅 번호를 입력하고 ETH를 지불하는 베팅 기능입니다. 여러 시드로 난수가 생성되며, 베팅 번호가 난수와 일치하면 사용자는 전체 상금 풀을 획득합니다.

채굴자의 공격 계약

채굴자들은 당첨 난수를 미리 계산하고 같은 블록 내에서 실행하기만 하면 승리할 수 있습니다. 이는 다음과 같은 한 가지 기능을 포함합니다:

attack(): 채굴자가 당첨 난수를 미리 계산하는 베팅 공격 기능입니다. 같은 블록 내에서 실행되므로 blockhash(block.number - 1)와 block.timestamp가 동일합니다. 그런 다음 채굴자는 주사위 계약의 Bet() 함수를 호출하여 공격을 완료합니다.

해결책

오라클 프로젝트에서 제공하는 오프체인 난수 사용

Chainlink과 같은 오라클 프로젝트가 제공하는 서비스를 통해 온체인 랜덤 숫자가 온체인 계약에 주입되어 무작위성과 보안성을 보장합니다. 그러나 오라클 프로젝트도 중앙화 위험을 수반하므로 더욱 성숙한 오라클 서비스가 필요합니다.

4. 재전송 공격

재전송 공격은 이전에 사용된 서명을 사용하여 트랜잭션을 다시 시작함으로써 자금을 훔치는 공격입니다. 최근 몇 년간 가장 잘 알려진 재전송 공격 중 하나는 Optimism의 마켓 메이커 Wintermute로부터 2천만 달러의 $OP 토큰을 도난당한 사건으로, 이는 크로스체인 재전송 공격이었습니다. Wintermute의 다중 서명 지갑 계정이 일시적으로 이더리움 메인넷에만 배포되었기 때문에, 해커는 이더리움에서 Wintermute의 다중 서명 주소 배포 트랜잭션 서명을 사용하여 Optimism 체인에서 동일한 트랜잭션을 재실행함으로써 Optimism의 다중 서명 지갑 계정을 제어할 수 있었습니다. 다중 서명 지갑 계정은 본질적으로 스마트 계약 계정이며, 이는 SCA와 EOA 사이의 중요한 차이점을 보여줍니다. EOA의 경우 일반 사용자는 이더리움과 EVM 호환 체인의 모든 주소를 제어하기 위해 하나의 개인 키만 필요하지만(주소 문자열이 정확히 동일함), SCA는 배포된 후 단 하나의 체인에서만 유효합니다.

구체적인 로직

여기서는 전형적인 재전송 공격(동일 체인 재전송 공격)의 예를 제공합니다. Bill은 각 트랜잭션을 실행하기 전에 전자 서명을 입력해야 하는 스마트 지갑을 가지고 있습니다. 이제 해커 Lucy가 Bill의 전자 서명을 훔쳤기 때문에, 그녀는 Bill의 스마트 지갑을 고갈시키기 위해 무제한으로 트랜잭션을 시작할 수 있습니다.

예시

취약점이 있는 계약은 세 가지 기능으로 구성됩니다:

checkSig(): ECDSA 검증 기능으로, 검증 결과가 원래 설정된 서명자임을 보장합니다.
getMsgHash(): 해시를 생성하는 기능으로, to와 amount를 결합하여 해시를 형성합니다.
transfer(): 이체 기능으로, 사용자가 유동성 풀에서 자금을 인출할 수 있게 합니다. 서명에 대한 제한이 없기 때문에 동일한 서명을 재사용할 수 있어 해커가 지속적으로 자금을 훔칠 수 있습니다.

해결책

재생 공격을 방지하기 위해 서명 조합에 nonce를 포함시킵니다. 매개변수의 원리는 다음과 같습니다:

nonce: 블록체인 네트워크에서 EOA의 트랜잭션 수를 나타내는 변수입니다. 순서와 고유성을 가지고 있습니다. 트랜잭션이 추가될 때마다 nonce 값은 1씩 증가합니다. 블록체인 네트워크는 트랜잭션의 nonce가 계정의 현재 nonce와 일치하는지 확인합니다. 따라서 해커가 이미 사용된 서명을 사용하려고 해도 서명 조합의 nonce 값이 EOA의 현재 nonce 값보다 작기 때문에 실패하게 됩니다.

5. 서비스 거부 (DoS) 공격

서비스 거부 (DoS) 공격은 전통적인 Web2 세계에서 새로운 것이 아닙니다. 이는 대량의 쓰레기 정보나 방해 정보를 보내는 등 서버를 방해하여 가용성을 저해하거나 완전히 파괴하는 모든 간섭을 의미합니다. 마찬가지로 스마트 계약도 이러한 공격에 시달리고 있으며, 본질적으로 스마트 계약의 오작동을 목표로 합니다.

구체적인 논리

예를 들어 보겠습니다. 프로젝트 A는 프로토콜 토큰에 대한 공개 모집을 진행하고 있으며, 모든 사용자는 선착순으로 할당량을 구매하기 위해 유동성 풀(스마트 계약)에 자금을 기여할 수 있고, 초과 자금은 참가자들에게 반환됩니다. 해커 Alice는 공개 모집에 참여하기 위해 공격 계약을 이용합니다. 유동성 풀이 Alice의 공격 계약에 자금을 반환하려고 하면 DoS 공격이 트리거되어 반환 작업이 실현되지 않습니다. 그 결과, 대량의 자금이 스마트 계약에 잠기게 됩니다.

공개 모집 계약 예시

예시

공개 모집 계약은 두 가지 기능을 포함합니다:

deposit(): 입금 기능으로, 입금자의 주소와 기여한 금액을 기록합니다.
refund(): 환불 기능으로, 프로젝트 팀이 투자자에게 자금을 반환합니다.

DoS 공격 계약

DoS 공격 계약은 한 가지 기능을 포함합니다:

attack(): 공격 기능이지만 자체적으로는 문제가 없습니다. 주요 문제는 Hacker 계약에 내장된 receive() 지불 콜백 함수에 있으며, 이 함수는 예외 판단을 포함합니다. Hacker 계약으로 자금을 이체하는 모든 외부 계약은 revert()를 통해 예외를 발생시켜 작업 완료를 방해합니다.

해결책

1. 외부 계약 호출 시 중요한 기능이 멈추지 않도록 합니다

PublicSale 계약의 위 refund() 함수에서 require(success, "Refund Fail!"); 를 제거하여 단일 주소로의 환불이 실패하더라도 환불 작업이 계속될 수 있도록 합니다.

2. 분리

PublicSale 계약의 위 refund() 함수에서 환불을 배포하는 대신 사용자가 직접 환불을 요청할 수 있도록 하여 외부 계약과의 불필요한 상호 작용을 최소화합니다.

6. permit 공격

허가 공격에서는 계정 A가 미리 지정된 당사자에게 서명을 제공하고, 계정 B는 이 서명을 얻은 후 승인된 토큰 전송을 실행하여 일정량의 토큰을 탈취할 수 있습니다. 여기서는 주로 스마트 계약에서 토큰 승인에 사용되는 두 가지 일반적인 함수인 approve()와 permit()에 대해 논의합니다.

일반적인 ERC20 계약에서 계정 A는 approve()를 호출하여 계정 B에게 일정량의 토큰을 승인할 수 있으며, 이를 통해 계정 B는 계정 A로부터 해당 토큰을 전송할 수 있습니다. 또한, EIP-2612에서 permit() 함수가 ERC20 계약에 도입되었고, Uniswap은 2022년 11월에 Permit2라는 새로운 토큰 승인 표준을 발표했습니다.

구체적인 로직

다음은 예시입니다. 어느 날 빌이 블록체인 뉴스 웹사이트를 탐색하던 중 갑자기 Metamask 서명 팝업이 나타났습니다. 많은 블록체인 웹사이트나 애플리케이션이 사용자 로그인 확인을 위해 서명을 사용하기 때문에 빌은 크게 신경 쓰지 않고 바로 서명을 완료했습니다. 5분 후, 그의 Metamask 자산이 모두 빠져나갔습니다. 빌은 블록체인 탐색기에서 알 수 없는 주소가 permit() 트랜잭션을 시작한 후 transferFrom() 트랜잭션을 통해 그의 지갑을 비웠다는 것을 발견했습니다.

예시

두 함수는 다음과 같습니다:

approve(): 계정 A가 계정 B에게 일정 금액을 승인하는 표준 승인 함수입니다.
permit(): 계정 B가 서명 확인을 제출하고 완료하여 계정 A로부터 승인된 금액을 얻는 서명 승인 함수입니다. 매개변수에는 승인을 부여하는 소유자, 승인받는 사용자, 승인된 금액, 서명 만료 시간, 그리고 소유자의 서명 데이터 v, r, s가 포함됩니다.

해결책

1. 온체인 상호작용에서 모든 서명에 주의를 기울이세요

일부 지갑이 approve() 승인 서명 정보를 해독하고 표시하기 위한 조치를 취하고 있지만, permit() 서명 피싱에 대해서는 거의 경고를 제공하지 않아 공격 위험이 증가합니다. 따라서 알 수 없는 모든 서명을 엄격히 검사하여 permit() 함수를 대상으로 하는지 확인하는 것이 강력히 권장됩니다.

2. 일상적인 상호작용을 위한 지갑과 자산을 저장하는 지갑을 분리하세요

이는 암호화폐 사용자, 특히 에어드롭 사냥꾼에게 매우 중요합니다. 그들은 매일 수많은 dApp이나 웹사이트와 상호작용하며 함정에 빠지기 쉽습니다. 일상적인 상호작용을 위한 지갑에 소량의 자금만 보관하면 손실을 관리 가능한 범위 내로 유지할 수 있습니다.

7. 허니팟 공격

블록체인 산업에서 허니팟 공격은 프로젝트 팀이 배포한 악의적인 토큰 계약의 한 유형을 말합니다. 이 계약은 프로젝트 팀에게만 판매 권한을 부여하며, 일반 사용자는 판매가 아닌 구매만 할 수 있어 손실을 입게 됩니다.

구체적인 논리

다음은 예시입니다. 텔레그램 공지에서 프로젝트 A는 사용자들에게 토큰이 메인넷에 배포되어 거래가 가능하다고 알립니다. 토큰은 구매만 가능하고 판매할 수 없기 때문에 처음에는 가격이 계속 상승하고, 기회를 놓칠까 두려워하는 사용자들이 계속 구매합니다. 시간이 지나 사용자들이 판매할 수 없다는 것을 알게 되면, 프로젝트 팀은 이 기회를 틈타 토큰을 대량 매도하여 가격을 폭락시킵니다.

예시

핵심 기능:

_beforeTokenTransfer(): 토큰 이체 중에 호출되는 내부 함수로, 소유자가 호출할 때만 성공할 수 있습니다. 다른 계정에서의 호출은 실패합니다.

해결책

보안 스캐닝 도구 사용

a. 이더리움 토큰을 위한 토큰 스니퍼

b. 다른 체인의 토큰을 위한 Ave Check

c. Dextools와 같이 내장된 감지 도구가 있는 시장 웹사이트

낮은 점수의 토큰 거래를 피하세요.

8. 선행매매 공격

선행매매는 원래 전통적인 금융 시장에서 발생했으며, 정보의 비대칭성으로 인해 금융 중개인들이 특정 업계 정보를 기반으로 신속한 조치를 취하여 이익을 얻을 수 있었습니다. 블록체인 산업에서 선행매매는 주로 온체인 선행매매에서 발생하며, 이는 채굴자들이 자신의 거래를 우선적으로 체인에 패킹하도록 조작하여 이익을 얻는 것을 포함합니다.

블록체인 분야에서 채굴자들은 블록에 패킹하는 거래를 조작하여 이익을 얻을 수 있습니다. 예를 들어, 특정 거래를 제외하거나 거래 순서를 재배열하는 등의 방법이 있습니다. 이러한 이익은 채굴자 추출 가능 가치(MEV)로 측정될 수 있습니다. 사용자의 거래가 이더리움 메인넷에 추가되기 전에 대부분의 거래는 멤풀에 집계됩니다. 채굴자들은 이 멤풀에서 더 높은 가스 가격의 거래를 찾아 우선적으로 패킹하여 이익을 극대화합니다. 일반적으로 가스 가격이 높은 거래일수록 채굴자들에 의해 더 쉽게 패킹됩니다. 한편, 일부 MEV 봇들도 수익성이 있는 거래를 찾기 위해 멤풀을 검색합니다.

구체적인 로직

다음은 예시입니다. 빌은 가격 변동이 큰 새로운 인기 토큰을 발견합니다. 유니스왑에서 토큰 거래의 성공을 보장하기 위해 빌은 예외적으로 넓은 슬리피지 범위를 설정합니다. 불행히도 앨리스의 MEV 봇이 멤풀에서 이 거래를 감지하고 즉시 가스 수수료를 인상하여 빌의 거래 전에 구매 거래를 시작하고 빌의 거래 후에 동일한 블록 내에 판매 거래를 삽입합니다. 블록 확인 후, 이로 인해 빌은 상당한 슬리피지 손실을 입게 되고, 앨리스는 저가 구매 및 고가 판매의 차익거래로 이익을 얻게 됩니다.

예시

함수는 다음과 같습니다:

solve(): 누구나 답을 제출할 수 있는 추측 함수로, 제출된 답이 목표 답과 일치하면 제출자는 10 이더를 받을 수 있습니다.

과정: Bill이 정답을 찾습니다.
Alice는 mempool을 모니터링하며 누군가가 정답을 제출하기를 기다립니다.
Bill은 solve()를 호출하여 답을 제출하고 가스 가격을 100 Gwei로 설정합니다.
Alice는 Bill이 보낸 거래를 보고 답을 발견합니다. 그녀는 Bill보다 높은 200 Gwei의 가스 가격을 설정하고 solve()를 호출합니다.
Alice의 거래가 Bill의 거래보다 먼저 채굴자에 의해 패킹됩니다.
Alice가 10 이더의 보상을 받습니다.

해결책

세 가지 주요 함수는 다음과 같습니다:

commitSolution(): 결과를 제출하는 함수로, 사용자가 제출한 답 solutionHash, 제출 시간 commitTime, 그리고 상태 revealed를 Commit 구조체에 저장합니다.
getMySolution(): 결과를 얻는 함수로, 사용자가 자신이 제출한 답과 관련 정보를 볼 수 있게 합니다. 여기에는 사용자가 제출한 답 solutionHash, 제출 시간 commitTime, 그리고 상태 revealed가 포함됩니다.
revealSolution(): 퍼즐 정답 맞추기에 대한 보상을 청구하는 함수로, 사용자가 답과 자신이 설정한 비밀번호를 제공한 후 보상을 청구할 수 있게 합니다.

과정:

Bill이 올바른 답을 찾습니다.
Bill은 commitSolution()을 호출하여 정답을 제출합니다.
다음 블록에서 Bill은 revealSolution()을 호출하며, 보상을 받기 위해 설정한 답변과 비밀번호를 제공합니다.

commitSolution()에서 Bill은 암호화된 문자열을 제출하여 평문 데이터를 자신만 알 수 있게 합니다. 이 단계에서 제출 블록 시간인 commitTime도 기록됩니다. 다음으로, revealSolution()에서는 같은 블록 내 프론트러닝을 방지하기 위해 블록 시간을 확인합니다. revealSolution() 호출 시 평문 답변 제출이 필요하므로, 이 단계는 다른 사람들이 commitSolution()을 우회하고 직접 revealSolution()을 호출하는 것을 방지합니다. 검증이 성공적으로 완료되면 답변이 정확한지 확인 후 보상이 지급됩니다.

결론

스마트 계약은 블록체인 기술에서 중요한 역할을 하며 많은 이점을 제공합니다. 첫째, 분산화된 자동 실행을 가능하게 하여 제3자 없이 거래의 안전성과 신뢰성을 보장합니다. 둘째, 스마트 계약은 중개 단계와 비용을 줄여 거래 효율성을 높입니다.

이러한 많은 이점에도 불구하고 스마트 계약은 사용자에게 금전적 손실을 초래할 수 있는 공격 위험에 직면해 있습니다. 따라서 온체인 사용자에게는 몇 가지 필수적인 습관이 있습니다. 첫째, 사용자는 상호작용할 dApp을 신중하게 선택하고 계약 코드와 관련 규칙을 철저히 검토해야 합니다. 또한 해커 공격의 위험을 줄이기 위해 안전한 지갑과 계약 상호작용 도구를 정기적으로 업데이트하고 사용해야 합니다. 더불어 계약 공격으로 인한 잠재적 손실을 최소화하기 위해 자금을 여러 주소에 분산 보관하는 것이 좋습니다.

업계 참여자들에게 스마트 계약의 보안과 안정성을 확보하는 것은 동등하게 중요합니다. 가장 우선적으로 스마트 계약의 감사를 강화하여 잠재적인 취약점과 보안 위험을 식별하고 수정해야 합니다. 둘째, 업계 참여자들은 계약 공격과 관련된 최신 블록체인 발전 사항을 파악하고 그에 따른 보안 조치를 취해야 합니다. 마지막으로 중요한 점은 스마트 계약의 올바른 사용에 대한 사용자 교육과 보안 인식을 강화해야 한다는 것입니다.

결론적으로, 사용자와 업계 참여자들의 공동 노력으로 스마트 계약으로 인한 보안 위험을 크게 줄일 수 있습니다. 사용자는 항상 신중하게 계약을 선택하고 개인 자산을 보호해야 하며, 업계 참여자들은 계약 감사를 강화하고 기술 발전을 주시하며 사용자 교육과 보안 인식을 높여야 합니다. 함께 노력하여 스마트 계약의 안전하고 신뢰할 수 있는 발전을 이끌어 나갈 것입니다.

참고 문헌:

Solidity by Example：https://solidity-by-example.org/

Blockchain Know-how of SlowMist：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 DeFi Security Best Practices：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Contract Security：https://www.wtf.academy/solidity-104/

Vulnerabilities in DeFi Smart Contracts in 4 Categories with 38 Scenarios：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/

스마트 계약의 일반적인 취약점 및 공격에 대한 소개