스마트 계약을 보호하는 방법은 무엇입니까? (보안 체크리스트)

코드 감사 및 공식 검증

1. 여러 독립 보안 ​​회사를 참여시켜 배포 전에 수동 코드 검토를 수행합니다.

2. Certora 또는 MythX와 같은 공식 검증 도구를 적용하여 중요한 불변성의 정확성을 수학적으로 증명합니다.

3. 검사 효과 상호 작용 패턴을 사용하여 재진입 벡터에 대해 모든 외부 호출이 검증되었는지 확인합니다.

4. OpenZeppelin 계약을 포함하여 가져온 모든 라이브러리에 버전별 취약점이 있는지 감사합니다.

5. 각 커밋을 해당 검증 보고서 및 타임스탬프에 연결하는 불변의 감사 추적을 유지합니다.

접근 제어 및 권한 관리

1. 감사 표준의 Ownable 또는 AccessControl 패턴을 사용하여 역할 기반 액세스 제어를 구현합니다.

2. 관리 기능과 사용자 대면 논리를 엄격하게 분리하여 공개 진입점에서 권한 있는 작업을 수행하지 않습니다.

3. 일시 중지, 업그레이드 또는 자금 인출과 같은 민감한 작업에 대해 다중 서명 승인을 요구합니다.

4. 관리 키를 정기적으로 교체하고 GitHub 리포지토리나 일반 텍스트 파일이 아닌 하드웨어 보안 모듈을 사용하여 오프라인으로 저장합니다.

5. 전체 컨텍스트(호출자, 타임스탬프, 대상 역할 및 이전 소유자)와 함께 모든 권한 변경 사항을 온체인에 기록합니다.

가스 최적화 및 런타임 보호

1. 실행 중에 가스 부족 오류를 일으킬 수 있는 무제한 루프를 피하십시오. 페이지 매김 또는 제한 반복을 사용하십시오.

2. 무한 폴백 루프를 통한 DoS를 방지하기 위해 외부 호출에 명시적인 가스 제한을 삽입합니다.

3. 스택 오버플로나 자동 잘림을 방지하려면 배열이나 문자열을 처리하기 전에 입력 길이와 범위를 확인하세요.

4. 사용자 제공 값과 관련된 모든 산술 연산에 대해 SafeMath 또는 Solidity 0.8+ 내장 오버플로 검사를 사용하십시오.

5. 프로덕션 오류 메시지에 민감한 논리를 노출하지 않고 디버깅을 돕기 위해 되돌리기 문자열을 활성화하여 배포합니다.

업그레이드 가능성 및 프록시 패턴

1. 업그레이드 논리가 비즈니스 논리와 완전히 분리된 상태로 유지되어야 하는 경우에만 투명 프록시를 선호합니다.

2. 무단 업그레이드를 방지하기 위해 프록시 자체가 아닌 별도의 강화된 계약에 프록시 관리자 주소를 저장합니다.

3. 정족수 시행 투표 기간이 있는 시간 고정 DAO에 의해 관리되지 않는 한 메인넷 출시 후 업그레이드 기능을 동결합니다.

4. 새로운 로직을 배포하기 전에 Slither 또는 Crytic-tool을 사용하여 구현 간 스토리지 레이아웃 호환성을 확인합니다.

5. 명시적으로 화이트리스트에 등록하고 기록하지 않는 한, 업그레이드 기능 내에서도 임의 주소에 대한 자체 파괴 또는 위임 호출을 허용하지 마십시오.

모니터링, 경고 및 사고 대응

1. Tenderly 또는 BlockSec를 통해 실시간 트랜잭션 추적을 통합하여 비정상적인 상태 전환을 감지합니다.

2. 갑작스러운 잔액 감소, 예상치 못한 소유권 이전 또는 반복적인 복귀와 같은 중요한 상황에 대해 온체인 이벤트 감시자를 설정합니다.

3. 암호화된 채널을 통해 공개 Slack 또는 Discord 그룹이 아닌 지정된 응답자에게 경고를 라우팅합니다.

4. 확인된 손상 후 몇 초 내에 방송할 수 있도록 미리 서명된 비상 일시 중지 트랜잭션을 유지합니다.

5. 거버넌스 다중 서명으로 서명된 IPFS 지원 Merkle 루트를 사용하여 매주 모든 기록 상태 스냅샷을 보관합니다.

자주 묻는 질문

Q: Slither나 Mythril과 같은 자동화된 스캐너에만 의존할 수 있나요? 자동화된 도구는 알려진 패턴을 포착하지만 토큰경제학 또는 상호 작용 모델에 고유한 논리 결함을 놓칩니다. 사람의 검토는 여전히 필수적입니다.

Q: GitHub의 ERC-20 템플릿을 수정 없이 사용하는 것이 안전한가요? 아니요. 널리 사용되는 많은 템플릿에는 컴파일러 버전, 누락된 수정자 또는 안전하지 않은 전송 의미 체계에 대한 오래된 가정이 포함되어 있습니다. 각 줄에는 상황별 유효성 검사가 필요합니다.

Q: 자체 소멸 기능을 사용하여 계약을 배포해야 합니까? 자폭은 되돌릴 수 없는 위험을 초래합니다. 테스트에 필요한 경우 컴파일 타임 플래그 또는 조건부 컴파일을 사용하여 메인넷 출시 전에 영구적으로 비활성화하세요.

Q: 라이브 계약의 관리 키를 얼마나 자주 교체해야 합니까? 개인 키는 스마트 계약을 직접 관리하지 않으므로 배포 후에는 관리자 키 순환이 적용되지 않습니다. 대신, 거버넌스 서명자를 순환시키고 시간 잠금 제안을 통해 다중 서명 임계값을 업데이트하세요.