폴리곤에 컨트랙트를 배포하는 팀은 내부 코드리뷰, 테스트와 정적 분석, 외부 감사, 배포 후 소스 검증 순서로 작업을 마무리하는 것이 안전합니다. 폴리곤은 이더리움과 같은 EVM 호환 환경이지만 블록 생성 속도, 가스 정책, 브리지 토큰 주소처럼 체인마다 다른 조건이 있습니다. 이 차이를 리뷰 항목에 넣고, 마지막에 배포된 바이트코드가 공개한 소스와 같은지 증명해야 검토 작업이 끝났다고 볼 수 있습니다.
폴리곤 스마트 컨트랙트는 이더리움 컨트랙트와 무엇이 다른가요?
미국 국립표준기술연구소(NIST)는 블록체인 기술 개요 보고서(NISTIR 8202)에서 블록체인을 변조 흔적이 드러나고 변조에 저항하는 분산 원장으로 설명하며, 정상 운영 중에는 게시된 트랜잭션을 바꿀 수 없다고 밝힙니다. 이 설명에 비추어 보면 배포 이후 코드를 고치기 어렵다는 점은 체인과 관계없이 같습니다. 그래서 배포 전 검토의 중요도도 체인마다 다르지 않습니다.
그러나 폴리곤 스마트 컨트랙트는 이더리움에서 쓰던 코드를 그대로 옮겼을 때 다음과 같은 차이에서 문제가 생기는 경우가 많습니다.
- 체인 식별자: 폴리곤 PoS 메인넷의 체인 ID는 137입니다. 서명 검증(EIP-712 도메인 등)에 체인 ID를 하드코딩했다면 테스트넷과 메인넷 값을 다시 확인해야 합니다.
- 토큰 주소: 브리지를 거친 USDC, WETH 같은 자산은 이더리움과 주소가 다르고, 같은 이름의 토큰이 여러 버전으로 있을 수 있습니다. 화이트리스트 주소는 하나씩 대조해야 합니다.
- 블록 시간과 재구성: 블록이 빠르게 생성되므로 block.number로 시간을 계산하는 로직은 기대한 기간과 실제 기간이 크게 어긋날 수 있습니다. 시간 조건은 block.timestamp를 기준으로 쓰고 허용 오차를 두는 편이 안전합니다.
- 가스 비용 가정: 가스비가 낮다는 이유로 반복문이나 대량 처리 로직을 느슨하게 짜면 블록 가스 한도에 걸리거나 서비스 거부 공격의 통로가 될 수 있습니다.
스마트 컨트랙트 코드 리뷰는 어떤 순서로 진행해야 하나요?
스마트 컨트랙트 코드 리뷰는 처음부터 코드를 한 줄씩 읽어 나가기보다 범위와 위협 모델을 먼저 정하고 나서 세부 검토로 들어가야 효율적입니다. 미국 사이버보안·인프라보안청(CISA)은 보안 소프트웨어 개발 프레임워크 SSDF(PW 7.2, RV 1.2)를 인용해 동료 코딩 표준에 따른 코드 리뷰를 권고합니다. 실무에서는 다음 순서로 진행할 수 있습니다.
- 범위 고정: 리뷰 대상 커밋 해시, 파일 목록, 외부 라이브러리 버전을 문서로 확정합니다. 범위가 흔들리면 검토 결과도 신뢰하기 어렵습니다.
- 권한 구조 정리: owner, admin, minter, pauser처럼 특권을 가진 역할과 각 역할이 호출할 수 있는 함수를 표로 정리합니다. 단일 키로 권한을 행사하는 구조라면 멀티시그나 타임락 적용 여부를 판단합니다.
- 자동 분석: 정적 분석 도구와 컴파일러 경고를 확인하고, 오탐인지 실제 문제인지 사유를 남깁니다.
- 수동 검토: 재진입, 외부 호출 순서, 정수 처리, 접근 제어 누락, 오라클 가격 조작 가능성, 업그레이드 프록시의 저장소 충돌을 중심으로 읽습니다.
- 테스트 보강: 리뷰에서 나온 가정은 단위 테스트, 퍼즈 테스트, 메인넷 포크 테스트로 확인합니다.
- 수정 확인: 지적 사항마다 수정 커밋을 연결하고, 수정 때문에 새 문제가 생기지 않았는지 다시 검토합니다.
스마트 컨트랙트 증명이란 정확히 무엇을 의미하나요?
현장에서 스마트 컨트랙트 증명이라는 말은 서로 다른 세 가지 작업을 가리킵니다. 이를 구분하지 않으면 "검증을 받았다"는 말이 실제로 무엇을 보장하는지 잘못 이해할 수 있습니다.
| 구분 | 증명하는 내용 | 증명하지 못하는 내용 | 확인 방법 |
|---|---|---|---|
| 소스코드 검증 | 배포된 바이트코드가 공개된 소스와 같은 컴파일 결과라는 점 | 코드에 취약점이 없다는 점 | 블록 익스플로러의 검증 표시, 컴파일 설정 대조 |
| 정형 검증 | 명세한 속성(예: 총공급량 불변)이 수학적으로 항상 성립한다는 점 | 명세에 넣지 않은 속성, 외부 컨트랙트의 동작 | 명세 문서와 검증 도구 결과 보고서 |
| 외부 감사 보고서 | 특정 시점과 범위의 코드를 전문 인력이 검토했다는 점 | 감사 이후 바뀐 코드, 운영 키 관리 상태 | 보고서의 커밋 해시와 배포 코드 일치 여부 |
세 가지 모두 완전한 안전을 보장하지는 않습니다. 소스 검증으로 투명성을 확보하고, 정형 검증으로 핵심 불변 조건을 확인하고, 외부 감사로 사람이 판단해야 하는 논리 오류를 찾는 방식으로 함께 쓰는 것이 좋습니다.
배포 후 소스 검증과 감사 범위는 어떻게 확인하나요?
소스 검증이 실패하는 원인은 대부분 컴파일 설정이 일치하지 않기 때문입니다. 배포 스크립트에서 아래 항목을 기록해 두면 검증 과정이 짧아집니다.
- 정확한 컴파일러 버전(nightly 여부 포함)과 EVM 버전 설정
- 최적화 사용 여부와 runs 값, viaIR 사용 여부
- ABI 인코딩된 생성자 인자
- 링크된 외부 라이브러리 주소
- 프록시 구조라면 프록시와 구현 컨트랙트 각각의 검증, 그리고 프록시가 가리키는 구현 주소
외부 감사를 맡길 때는 감사 대상 커밋 해시와 실제 배포 커밋이 같은지 계약 단계부터 정해 두어야 합니다. 업체별로 수동 검토 비중, 정형 검증 포함 여부, 수정 후 재검토 횟수가 다르므로 감사 서비스를 비교할 때도 이 항목들을 같은 기준으로 놓고 보는 것이 좋습니다. 특정 업체인 CertiK의 감사 서비스 소개 페이지(폴리곤스마트컨트랙트)는 비교 대상의 한 예시로 참고할 수 있습니다. 보고서를 받은 뒤에는 '확인됨', '부분 수정', '위험 수용'처럼 처리 상태가 항목별로 표시되어 있는지 살펴봐야 합니다.
취약점이나 사고를 발견하면 무엇을 먼저 해야 하나요?
운영 중에 취약점을 발견했다면 우선 일시 정지 기능이나 권한 회수로 피해 범위를 줄이고, 관련 트랜잭션 해시와 시각, 영향을 받은 주소를 보존해야 합니다. 국내에서는 한국인터넷진흥원(KISA)이 침해사고 신고 창구와 보호나라를 운영하고 있으므로 해킹이 의심되는 사고는 이 창구로 신고하고 도움을 받을 수 있습니다.
이용자 자산을 다루는 서비스라면 규제 요건도 함께 검토해야 합니다. 금융위원회 소관인 「가상자산 이용자 보호 등에 관한 법률」은 이용자의 예치금과 가상자산을 안전하게 보호하는 것을 다루고 있습니다. 서비스 구조에 따라 적용 여부가 달라질 수 있으므로 구체적인 의무 범위는 법률 전문가와 상담해 확인하시기 바랍니다.
사고가 정리된 뒤에는 원인 분석 결과를 코드리뷰 체크리스트에 다시 반영해야 같은 유형의 문제가 반복되지 않습니다. 발견된 취약점의 근본 원인을 분석해 이후 개발 절차를 개선하는 것이 바람직합니다.
자주 묻는 질문
블록 익스플로러에서 소스 검증 표시가 있으면 안전한 컨트랙트인가요?
그렇지 않습니다. 소스 검증 표시는 공개된 소스가 실제 배포 코드와 같다는 사실만 보여 줍니다. 그 소스에 취약점이나 과도한 관리자 권한이 있는지는 따로 검토해야 합니다.
이더리움에서 감사를 받은 코드를 폴리곤에 그대로 배포해도 됩니까?
코드가 같더라도 체인 ID, 토큰 주소, 오라클 피드, 블록 시간 가정이 달라질 수 있습니다. 최소한 체인 의존 설정을 다시 검토하고 포크 테스트를 수행하는 것이 좋으며, 설정 이외의 코드가 바뀌었다면 해당 부분은 다시 감사받는 것을 권합니다.
내부 코드리뷰만으로 외부 감사를 대신할 수 있습니까?
규모가 작고 자산이 적은 컨트랙트는 체계적인 내부 리뷰와 테스트로도 위험을 상당히 줄일 수 있습니다. 다만 이용자 자금을 맡거나 업그레이드 권한이 있는 구조라면 작성자와 독립된 외부 검토를 함께 받는 것이 일반적인 권고입니다.