글에서 소개한 AI 보안 솔루션들은 크게 3가지입니다.

1. AIxCC (미 국방성 개최 AI 보안 솔루션 대회) 에 출전한 솔루션들
• 퍼징을 자동화하는데에 집중되어있고, 완전히 새로운 방식보다는 기존 도구를 AI에 잘 엮는 형태가 대부분이었음. 취약점 탐지 이후 패치 작업에 대해서는 파인튜닝된 모델 사용

2. 구글의 Big Sleep
• 인간 보안연구원의 행동을 모방한 에이전트. 주로 C 코드에서의 메모리 취약점 발견, address sanitizer로 증명
• 취약점 패치는 못하고 탐지만 가능. 현재 구글에서 개발중인 CodeMender 프로젝트가 이를 개선할 것으로 기대됨

3. OpenAI의 Aardbark
• 버그 탐지에 집중한다기보다는 인간 연구원을 보조할 수 있는 추론 능력 기반의 어시스턴트에 가까울 것으로 예상됨

글에서는 현재 바이브코딩 시대 프로그램들이 코드가 균일하지 않고 보안 방식이 제각각이라 기존의 보안 시스템이 일관되게 적용되기 힘들다. 특히 AI 보안 시스템은 취약점 식별과 패치에 할루시네이션을 많이 겪는다. 그럼에도 이 문제를 해결할 도구는 AI가 될 것이며, 특수 목적의 모델과 에이전트 시스템이 점차 발전할 것으로 기대한다고 정리하고있습니다.

1위: Team Atlanta의 Atlantis
• 조지아텍, 삼성리서치, 카이스트, 포스텍 연합팀
• 퍼징 + symbolic execution + 파인튜닝한 자체 모델
• 언어별 / 단계별로 다른 전략의 에이전트 사용
• https://github.com/Team-Atlanta/aixcc-afc-atlantis

2위: Trail of Bits의 Buttercup
• 전통퍼징도구 (libfuzzer 등) + 비추론 LLM => 높은 비용효율성
• https://github.com/trailofbits/buttercup

3위: 티오리의 Roboduck
• 전통 바이너리 분석기법보다는 최신 LLM에 코드 분석 의존. 전통기법은 백업으로 사용
• 인간 보안연구원 워크플로우 재현하는 방향
• 상용 보안솔루션 Xint Code로 개발중
• https://github.com/theori-io/aixcc-afc-archive

4위: All You Need IS A Fuzzing Brain의 Fuzzing Brain
• Roboduck과 마찬가지로 LLM 의존, 퍼징 폴백
• 23개의 서로 다른 LLM 전략 병렬 실행
• https://github.com/o2lab/afc-crs-all-you-need-is-a-fuzzing-brain

5위: Shellphish의 Artiphishell
• UC 산타바바라, 애리조나주립대, 퍼듀 연합팀
• LLM 커버리지 피드백 기반으로 진화하는 문법 생성, 복잡한 입력 포맷 퍼징에 특화된 GrammarGuy 개발
• 정적 분석 - 동적 분석 - 트리아지 - 패칭으로 이어지는 파이프라인

6위: 42-b3yong-bug의 BugBuster
• 노스웨스턴대 등 연합
• 퍼징 중심의 취약점 탐지
• 취약점 탐지 개수는 2위 였으나 패치 성공률이 낮아 최종순위가 낮았음

7위: 미국 방산기업 SIFT의 Lacrosse
• 10년 전의 기존 시스템을 현대화
• 퍼징 + symbolic reasoning
• https://github.com/siftech/afc-crs-lacrosse

- 1,200만 cUSD
- Frontier 프로그램 참여자 대상

- caps당: 0.000027772 cUSD
- COG당: 0.000021267 cUSD

- FDV $250M의 5%
- 기존 스테이블코인 에어드랍 비율 준수
- YT-cUSD 홀더 리스크 보상 기준
- 시장 기대치 초과 달성

- Frontier 종료
- Homestead 시작 (cUSD 보유로 caps 적립)

결론

- EOA 서명이 아닌, 패스키 등 UX 친화적 서명 알고리즘
- 양자 저항 서명 알고리즘
- 가스비 대납
- 트랜잭션 배칭

EIP-8141은 트랜잭션을 여러 프레임으로 구분하고, 각 프레임을 트랜잭션 전송자가 자유롭게 구성할 수 있도록 합니다. 프레임에는 일반적인 스마트 컨트랙트 호출 뿐만 아니라, ‘커스텀 서명 검증 단계’도 넣을 수 있습니다. 해당 단계에서는 기존 ECDSA 서명 뿐만 아니라, 패스키 / 멀티시그 / 양자 저항 키 등등 다양한 검증 로직을 구현할 수 있으며, 이 단계를 통해 트랜잭션의 유효성이 판단될 뿐만 아니라, 가스를 누가 내는지도 결정할 수 있게 되죠. 이 검증 단계를 명시하기 위해, EIP-8141은 APPROVE라는 새로운 명령어(opcode)를 도입합니다. 이 명령어는 컨트랙트가 이더리움 노드에게 ‘이 트랜잭션이 유효한지, 그리고 가스는 누가 낼지’를 전달하는 역할을 수행하죠. 즉, 컨트랙트 계정은 이제 검증 로직을 알아서 구현하고, 끝에다가 APPROVE 명령어를 갖다가 붙이면 됩니다.

프레임은 매우 자유로워서, 기존 EOA 트랜잭션 형태도 지원하는 반면, 트랜잭션 배칭 / 가스비 대납 등 유용한 유즈케이스까지 완벽히 지원될 수 있습니다.

또한, 계정 추상화 지갑이나 서비스를 구현하는 빌더들은 종종 고민에 빠지게 될 때가 있습니다. 커스텀한 검증과 실행을 지원하는 월렛들의 특성 상, 사용처에 따라 검증 스텝에서 쓴 정보를 실행 과정에서 필요로 할때도 있는 등, EVM에서 기본 제공하는 맥락 외 추가 정보가 필요할 때가 많습니다. 이를 위해, EIP-8141은 TXPARAM 명령어를 지원합니다. 이 명령어는 트랜잭션 내 다양한 필드들의 정보를 네이티브한 명령어로 쉽게 불러올 수 있도록 하여, 컨트랙트 함수 실행에 필요한 맥락을 제공하기 위해 이상한 필드에 추가 정보를 억지로 끼워 넣는 등의 행위를 안 해도 되게 만듭니다. ERC-4337에서 조금 더 빌더 친화적으로 진화했다고 볼 수 있겠네요.

- EIP-7701은 트랜잭션의 검증과 실행을 위해 프로토콜이 고정된 형태의 함수를 부르도록 하여, 월렛 개발자들이 지정된 함수를 컨트랙트 월렛 내에 구현해야만 했습니다. 반면, EIP-8141은 이를 명령어 형태로 정형화하여 훨씬 자유롭게 만들었습니다. 이제 빌더들은 컨트랙트 단의 제약이 크게 없이, 훨씬 자유롭게 코드를 작성할 수 있습니다.

- 이에 따라 노드 단에서 ABI 인코딩 등을 하지 않아도 되니 노드 단에서 코드도 더욱 단순해집니다.

- 또한, 위에서 이야기 하였듯, TXPARAM 명령어 덕분에 EIP-8141에서는 월렛 개발자가 쓸데없는 맥락 정보를 이상한 필드에 끼워넣는 행위를 하지 않아도 됩니다. 참고로, ERC-4337 월렛들을 보면 전혀 상관없는 데이터를 UserOperation 내 논스나 서명 필드에 끼워넣는 구현들이 있는데, EIP-8141에서는 이런 요상한 짓들을 하지 않아도 된다는 의미입니다.

- 다만 기존 이더리움 트랜잭션 형태를 크게 고치지 않으려는 형태다 보니, EIP-8141에서는 ERC-4337 / EIP-7701이 제공하던 일부 기능(e.g. 2D 논스)을 제공하지 않습니다.