이득:
- 인공 지능을 사용하여 입증된 라이브러리(예: OpenZeppelin)를 기반으로 프레임워크, 테스트 및 검토 초안을 생성하고 인간이 생산 보안을 보장한다는 것을 이해하는 능력
- 컴파일, 테스트, 테스트넷을 통해 인공지능이 생성한 코드 버전, 패턴, 접근 제어를 검증하는 능력
- 컴파일이 보안을 의미하는 것은 아니며 테스트넷과 감사가 필수적이라는 것을 구별할 수 있습니다.
스마트 계약을 작성하는 것은 일반 소프트웨어와 다릅니다. 작성하는 코드는 공개적이고 불변이며 돈을 직접 이동시키는 프로그램입니다. 이 단원에서는 AI를 스마트 계약 개발 보조자로 사용하는 방법을 배웁니다. 초안 제작부터 테스트 작성까지, 패턴 리콜부터 가스(거래 수수료) 최적화까지 학습합니다. 하지만 처음부터 분명히 해두자. AI는 청사진을 생성한다. 인간은 프로덕션에 들어가는 보안 코드를 보장합니다.
첫 번째: 언어와 환경
가장 일반적인 스마트 계약 언어는 Solidity(Ethereum 및 EVM의 언어 — Ethereum Virtual Machine, 계약이 실행되는 가상 머신 — 호환 가능한 체인)입니다. 대안은 Vyper(보다 제한적이고 읽기 쉬운 것을 목표로 하는 Python과 유사한 언어)입니다. 귀하의 코드는 가스(블록체인에 대한 각 거래 비용)를 소비합니다. 비효율적인 코드는 비용이 많이 듭니다. AI에 제공하는 맥락에서 이러한 용어를 명확하게 유지하는 것이 정확한 출력을 얻는 데 중요합니다.
AI가 가장 가치 있는 곳은 "처음부터 작성"하는 것이 아니라 프레임워크 + 좋은 틀을 생성하는 것입니다. 즉, 표준을 준수하는 시작, 전문 지식을 추가할 청사진입니다.
코딩에 AI를 사용하는 계층
1. 뼈대 생성. AI는 표준 토큰(ERC-20) 또는 NFT(ERC-721 - 고유한 디지털 자산 표준)의 골격을 신속하게 채굴합니다. 그러나 AI가 검증된 라이브러리(예: OpenZeppelin(커뮤니티에서 신뢰할 수 있고 감사를 받은 표준 계약 라이브러리))를 사용하도록 해야 합니다. 보안을 처음부터 작성하는 대신 테스트된 블록을 사용하는 것이 규칙입니다.
2. 기능 설명 및 검토. AI에게 기존 기능을 설명하면 논리 오류를 조기에 발견할 수 있습니다.
3. 테스트 생성. AI는 입력 없음, 매우 큰 숫자, 무단 호출자, 반복 호출 등 극단적인 경우에 대한 테스트 사례를 생성하는 데 능숙합니다. 이는 건너뛴 시나리오 중 하나를 상기시킵니다.
4. 가스 및 가독성. AI는 불필요한 스토리지 쓰기와 같은 비용이 많이 드는 패턴을 표시하고 대안을 제안합니다.
힌트: AI에게 "OpenZeppelin의 감사된 계약을 기반으로 구축하고 보안을 처음부터 다시 작성"하도록 지시하세요. 테스트된 라이브러리를 사용하는 것보다 AI가 원본 보안 코드를 작성하는 것이 훨씬 더 위험합니다.
약한 프롬프트 / 강한 프롬프트
약한 프롬프트:
토큰 계약서를 작성해 주세요.
이 메시지는 위험합니다. 어떤 표준, 어떤 체인, 어떤 라이브러리, 어떤 보안 요구 사항이 명확하지 않습니다. AI는 오래되었거나 안전하지 않은 코드를 무작위로 생성합니다.
강력한 프롬프트:
귀하의 역할: 수석 Solidity 개발자. EVM 호환 체인에 대한 ERC-20 토큰 초안을 생성합니다. 규칙:- OpenZeppelin의 감사된 ERC20 및 소유 가능 계약을 기반으로 합니다.- Solidity 버전 및 라이센스(SPDX) 줄을 명시적으로 작성합니다.- 소유자만이 발행 권한을 갖습니다. 무한한 누르기에 대한 캡을 추가하십시오. - 각 함수에 NatSpec 설명을 추가합니다. - 처음부터 보안을 작성합니다. 표준 블록을 사용하십시오. - 끝에 경고를 추가합니다: "이것은 초안입니다. 감사 및 테스트가 필요합니다." 확실하지 않은 영역은 // TODO로 표시하세요.
차이점: 강력한 프롬프트는 명확한 역할, 표준, 라이브러리, 보안 경계, 문서 및 검증 기대치를 제공합니다.
복사 가능한 템플릿 4개
1) 표준 기반 뼈대:
귀하의 역할: Solidity 개발자. OpenZeppelin 감사 라이브러리를 기반으로 [ERC-20 / ERC-721 / 스테이킹] 계약 프레임워크를 생성합니다. SPDX 라이센스 및 pragma 버전을 작성합니다. 각 외부 기능에 액세스 제어(통화할 수 있는 사람)를 추가합니다. 보안 재창조; 표준 블록을 사용하십시오. 이것은 초안입니다.
2) 기능 검토:
선임 개발자처럼 다음 기능을 살펴보세요. 이 기능이 수행하는 작업, 상태 변경, 호출할 수 있는 사람은 누구입니까? 가능한 논리 오류와 보안 위험을 가설로 표시하고 각각을 코드의 한 줄에 연결합니다. "안전하다"고 노골적으로 말하지 마세요. 주의점만 나열해 보세요.
3) 테스트 시나리오 초안:
이 계약에 대한 테스트 사례를 제안합니다(Foundry/Hardhat의 초안일 수 있음). 구체적으로 제한 사례를 다룹니다: 입력 없음, 매우 큰 숫자, 무단 호출, 재진입 호출, 자금 부족. 각 테스트에서 확인한 내용을 작성하세요.
4) 가스 및 가독성 검토:
본 컨트랙트에는 불필요한 스토리지 쓰기, 루프 내 외부 호출, 반복 계산 등 가스 비용을 줄일 수 있는 패턴을 표시합니다. 각 제안의 전후 차이점을 설명하세요. 보안을 깨는 최적화를 권장합니다. 명확하지 않은 경우 "감사관에게 문의하세요"라고 말합니다.
미니 케이스 3개(숫자 기준)
사례 1 - 스켈레톤이 4시간을 절약했습니다. 한 팀은 30분 만에 AI를 사용하여 감사된 도서관 기반 베스팅 계약의 뼈대를 채굴했습니다. 수동으로 ~ 4 시간이 걸렸습니다. 팀은 보안과 테스트에 시간을 할애했습니다. 이점은 보안 이전이 아니라 지루한 프레임워크의 속도를 높이는 데서 비롯되었습니다.
사례 2 - 오래된 버전 트랩. AI는 원시 Ether를 전송으로 보내는 패턴을 생성했는데, 이는 훈련 데이터가 오래되었기 때문에 더 이상 권장되지 않습니다. 개발자는 이를 알아차리고 현재 호출 기반 및 재진입 보호 패턴으로 변경했습니다. 교훈: AI의 라이브러리/패턴은 항상 최신 상태인지 확인됩니다. AI는 훈련 마감일 이후를 알지 못합니다.
사례 3 - 테스트 초안에서 숨겨진 버그가 발생했습니다. AI가 진행한 '무단 호출자' 테스트 결과 개발자가 함수에 대한 접근 제어를 잊어버린 것으로 드러났다. onlyOwner의 한 줄 누락, 테스트넷에서 5분 만에 포착됨; 메인넷에서 자금 손실이 발생할 수 있습니다. 교훈: AI는 테스트에서 인간의 사각지대를 커버합니다.
AI로 보안 패턴 기억
AI는 체크리스트와 같이 알려진 취약점 패턴을 상기시키는 데 능숙합니다. 가장 일반적인 패턴:
- 재진입: 상태를 업데이트하지 않고 외부 전화를 겁니다. 해결책: 검사-효과-상호작용 순서, 재진입 가드.
- 액세스 제어 부족: 누구나 중요한 기능을 호출할 수 있습니다.
- 정수 오버플로/하락: Modern Solidity는 대부분을 포착하지만 여전히 하위 수준 코드에서는 위험합니다.
- 부적절한 입력 검증: 주소 0, 수량 제어 0.
- Oracle 종속성: 외부 데이터(예: 가격)에 대한 맹목적인 신뢰입니다.
주의: AI는 이 목록을 기억할 수 있지만 목록의 항목이 특정 코드에 있는지 여부를 보장할 수는 없습니다. 체크리스트는 시작입니다. 이는 컨테이너 제어를 대체하지 않습니다.
컨텍스트를 올바르게 파악하기: AI에서 좋은 코드를 만드는 비결
AI가 생성하는 코드의 품질은 사용자가 제공하는 컨텍스트의 품질에 직접적으로 좌우됩니다. Web3에서는 하나의 작은 세부 사항(체인, Solidity 버전, 토큰 표준)이 전체 출력을 변경하기 때문에 이는 특히 중요합니다. 좋은 상황에는 다음이 포함됩니다.
- 대상 체인 및 환경: 이더리움 메인넷 또는 레이어 2(메인체인 위에서 실행되는 더 저렴한 사이드체인)? 가스 비용 및 일부 기능은 체인에 따라 다릅니다.
- 버전 및 라이브러리: 어떤 Solidity 버전, 어떤 OpenZeppelin 버전인가요? 버전이 지정되지 않으면 AI가 오래되고 더 이상 사용되지 않는 패턴을 생성할 수 있습니다.
- 보안 요구 사항: 한도가 있나요? 일시 중지할 수 있나요? 늘릴 수 있나요? 이런 말은 처음부터 말해야 합니다.
- 제약 조건: "어셈블리 사용 안 함", "외부 호출 방지", "가스 최적화하지만 가독성 유지"와 같은 명확한 제한 사항.
또 다른 강력한 기술은 AI에게 먼저 계획을 요청한 다음 코드를 요청하는 것입니다. "먼저 이 계약의 기능과 각각이 수행할 작업을 나열하고 내가 승인하면 코드를 작성합니다." 이를 통해 잘못된 방향으로 가는 AI를 조기에 포착하고 아키텍처 결정을 유지할 수 있습니다.
힌트: AI에게 "이 코드를 왜 이렇게 썼나요?"라고 물어보세요. 묻다. 근거를 설명하면 학습 속도가 빨라지고 논리적 오류(예: 잘못된 보안 가정)가 표면화됩니다. 자신의 코드를 방어할 수 없는 AI의 출력을 신뢰하지 마십시오.
일반적인 실수
- 처음부터 AI에 보안을 적용합니다. 테스트된 라이브러리를 사용하세요.
- AI가 생성한 버전/패턴을 확인하지 않습니다. 학습 데이터가 오래되었을 수 있습니다.
- 테스트넷 우회. 모든 초안은 라이브로 전환되기 전에 테스트 네트워크에서 실행되어야 합니다.
- NatSpec/문서를 추가하지 않습니다. 점검 및 유지보수가 어려워집니다.
- "컴파일되었으니 안전하다"는 오해. 컴파일된다고 해서 안전하다는 의미는 아닙니다.
- 액세스 제어를 잊어버렸습니다. 이는 가장 흔하고 비용이 많이 드는 실수 중 하나입니다.
요약하면
- 스마트 계약 작성에서 AI는 프레임워크, 테스트 및 검토 초안을 생성합니다. 인간은 생산의 안전을 보장합니다.
- 처음부터 보안을 구축하는 것이 아니라 입증된 라이브러리(예: OpenZeppelin)를 기반으로 보안을 구축하세요.
- YZ가 생산하는 버전과 패턴의 최신성은 항상 확인됩니다.
- 테스트 스텁은 사람의 사각지대(케이스 제한, 액세스 제어)를 포착하는 데 유용합니다.
- 컴파일된다고 해서 안전하다는 의미는 아닙니다. 테스트넷과 감사는 필수입니다.
응용과제
간단한 ERC-20 토큰의 경우 위의 "표준 기반 뼈대" 프롬프트를 사용하여 초안을 생성하세요. 그런 다음 (1) 확인된 라이브러리를 사용하는지 확인하고, (2) 액세스 제어를 확인하고, (3) "테스트 케이스 초안" 프롬프트로 테스트를 생성하고 실제로 적어도 하나의 악성 호출자 테스트를 실행합니다. AI가 놓친 보안 지점을 하나 이상 찾아서 기록해 두세요.
체크리스트
- [ ] 프롬프트에 표준과 체인을 명확하게 명시했습니다.
- [ ] 저는 입증된 라이브러리 기반 제작을 원했습니다.
- [ ] SPDX 라이센스 및 pragma 버전을 사용할 수 있습니다.
- [ ] 모든 중요한 기능에는 액세스 제어가 있습니다.
- [ ] 제한 사례에 대한 테스트를 만들고 실행했습니다.
- [ ] 라이브러리/패턴이 최신인 것을 확인했습니다.
- [ ] 감사 및 테스트를 위해 코드를 표시했습니다. 메인넷에서 감독되지 않은 상태로 진행되지 않았습니다.