Abstract L2 체인 개요와 설계 핵심: ZK Rollup, ZK Stack, 네이티브 계정 추상화, AGW

개요

Abstract는 이더리움 보안을 상속하는 ZK Rollup 기반 L2 체인으로, 고비용·저처리량 한계를 완화하는 확장 층 제공 목표 ZK Stack으로 구축되어 체인 개발과 운영 구성 요소를 모듈화하고, 데이터 가용성은 EIP-4844 블롭을 활용해 비용을 절감하는 방향 추구 핵심 차별점은 네이티브 계정 추상화 기반의 트랜잭션 수명주기와 글로벌 지갑 레이어를 통한 사용자 온보딩 간소화에 있음

배경과 목적

이더리움 메인넷의 처리량은 대략 초당 수십 건 수준이며, 수수료 변동성도 큼 저가치 대량 트랜잭션을 직접 L1에서 처리하는 것은 비현실적 L2의 목표는 탈중앙성과 보안을 유지하면서 처리량과 비용 효율을 동시에 개선하는 것 ZK Rollup은 유효성 증명을 통해 상태 전이를 압축·검증하여 온체인 데이터 요구량과 확정 시간을 줄이는 확장 경로 제공

핵심 개념

Layer 2
- L1의 합의와 보안을 상속받아 트랜잭션을 오프체인에서 처리한 후 압축된 증거를 L1에 제출하는 확장 계층
- 목표는 가스 비용 절감, TPS 증가, 빠른 최종성 확보
ZK Rollup
- 트랜잭션 배치를 실행한 결과가 올바름을 증명하는 유효성 증명 제출 방식
- 모든 원시 트랜잭션 데이터를 L1에 게시하지 않고 상태 변화의 유효성만 증명하여 확정 가능
- Optimistic Rollup 대비 사후 분쟁 윈도우 감소, 빠른 확정성 기대
ZK Stack
- ZK Rollup을 구성하기 위한 오픈 프레임워크
- 시퀀서, 증명기, 검증 계약, 데이터 가용성, 브리징 등 구성요소를 모듈 단위로 조립하는 설계 지향
데이터 가용성과 EIP-4844
- 상태 차이와 배치 관련 데이터를 블롭 형태로 게시하여 비용 효율을 높이는 전략
- 블롭 데이터는 일정 기간 보존되며, 검증과 재구성에 필요한 최소 요건 충족을 목표

동작 원리와 구조

트랜잭션 수명주기 개요

사용자가 JSON-RPC를 통해 L2 네트워크로 트랜잭션 제출, 멤풀 적재
시퀀서가 트랜잭션을 실행해 블록화 후 배치 생성
사용자에게 즉시 실행 응답 반환 가능, 최종성은 L1 커밋·검증 후 확보
배치가 L1로 전송되어 데이터 가용성 보장 상태로 커밋됨
ZK 증명이 생성되어 L1 검증 계약에서 확인됨
검증 완료 후 배치 실행 확정, 상태 루트와 로그가 온체인 기준으로 고정

L1 상호작용 단계

커밋 단계
- 시퀀서가 L1 롤업 컨트랙트에 배치 커밋 호출 수행
- EIP-4844 블롭을 통해 상태 차이 등 필요한 데이터의 가용성 보장
증명 단계
- 배치 실행의 유효성을 ZK 증명으로 생성하여 L1에 제출
- 검증 계약이 증명을 확인하여 상태 전이의 정당성 확립
실행 단계
- 검증 완료 즉시 배치가 확정 처리되며, L2 로그를 포함한 머클 구조가 저장됨

구성 요소

Sequencer 계층
- RPC 서비스: 트랜잭션 제출, 상태 조회 등 API 제공
- Sequencer: 트랜잭션 정렬·실행·블록화, 검증 제약을 준수하는 실행 파이프라인 유지
- L1 연동 오퍼레이터: 입금, 업그레이드 등 L1 이벤트 동기화 및 배치 커밋 전송 역할
Prover & Verifier 파이프라인
- 증인 생성 단계: 거래 세부 공개 없이 유효함을 입증하기 위한 데이터 구성
- 회로 실행 단계: VM 실행의 정합성을 검증하는 회로를 기준으로 증명 생성 및 검증 수행
  - 연산 코드, 스토리지 상호작용, 사전컴파일 통합 등을 포함하는 실행 정합성 보장 목표
  - 배치 전체를 순회하며 최종 상태 루트까지의 업데이트 일관성 확인
- 증명 압축 단계: L2에서 생성된 큰 STARK류 증명을 소형 SNARK류로 압축하여 L1 검증 비용 절감
L1 Rollup Contracts
- 블롭을 사용해 상태 차이와 압축된 바이트코드 저장
- 유효성 증명 수신·검증
- L1↔L2 메시징과 브리징 지원

네이티브 계정 추상화

Abstract의 모든 계정은 스마트 컨트랙트 계정으로 동작하며 동일한 트랜잭션 수명주기 준수 EOA와 CA 이원화 대신 IAccount 인터페이스 기반의 단일 모델 적용 EOA 지갑으로 서명해도 실행 경로에서는 기본 계정 구현체로 변환되어 처리됨 가스 지불은 본인 또는 페이마스터를 통해 유연하게 수행 가능

트랜잭션 플로우

제출
- JSON-RPC로 트랜잭션 제출, 멤풀 적재
- from 필드를 스마트 컨트랙트 계정 주소로 설정 가능
부트로더 처리
- 멤풀에서 트랜잭션을 읽어 배치 단위로 처리
- NonceHolder 시스템 컨트랙트 질의로 nonce 사용 여부 확인
- from 주소에 코드가 없으면 기본 계정 구현으로 해석해 실행 경로 표준화
스마트 컨트랙트 계정 검증·실행
- validateTransaction 호출로 실행 허용 여부 판단 및 접근 제어 수행
- executeTransaction 호출로 실제 실행 경로 진입
- payForTransaction 또는 prepareForPaymaster 호출로 가스 지불 경로 선택
페이마스터 경로 선택적 수행
- validateAndPayForPaymasterTransaction 호출로 후원 여부 결정 및 가스 지불 집행
- postTransaction 훅으로 사후 처리 로직 수행 가능

스마트 컨트랙트 지갑 설계 포인트

IAccount 인터페이스 구현 기반 표준 동작 확보
onlyBootloader 제약으로 부트로더 외 호출 차단
컨트랙트 배포는 시스템 컨트랙트를 통한 isSystemCall 경로 사용
효율적 실행을 위한 저수준 호출 라이브러리 활용 권장
가스 지불은 부트로더에 직접 지불 또는 페이마스터 입력 처리 함수 사용

Nonce 관리

트랜잭션 시작 전 NonceHolder 시스템 컨트랙트의 validateNonceUsage 호출로 중복 사용 방지 유효성 검사 단계에서 nonce를 소비 처리해야 함 옵션

minNonce 증가로 해당 값 미만 nonce 일괄 사용 처리
setValueUnderNonce를 통해 특정 nonce 슬롯에 0이 아닌 값 기록 편의 메서드 incrementMinNonceIfEquals 사용 권장 NonceHolder 호출에는 트랜잭션의 isSystem 플래그 설정 필요, 시스템 호출 유틸 사용 권장

서명 검증과 EIP-1271

스마트 컨트랙트 계정은 EOA와 달리 고정 서명 검증 로직이 없으므로 EIP-1271 구현 권장 isValidSignature를 통해 임의 로직으로 서명 유효성 판단 가능, EIP-712 타입 데이터 서명과 결합 시 사용자 경험 및 보안 개선 기대

contract ERC1271 {
  // bytes4(keccak256("isValidSignature(bytes32,bytes)"))
  bytes4 constant internal MAGICVALUE = 0x1626ba7e;

  function isValidSignature(
    bytes32 _hash,
    bytes memory _signature
  )
    public
    view
    returns (bytes4 magicValue)
  {}
}

Paymaster 개념

다른 계정을 대신해 가스비를 지불하는 스마트 컨트랙트 역할 IPaymaster 인터페이스 준수 필수 계정 소유자의 가스비 직접 지불을 대체해 비용 스폰서십, 토큰 기반 가스 지불 등 사용성 개선 제공 실행 경로에서는 prepareForPaymaster 이후 paymaster가 검증과 결제를 수행 오남용 방지를 위한 한도·쿨다운·화이트리스트 정책 필요

AGW(Abstract Global Wallet) 개요

네이티브 계정 추상화를 전제로 한 사용자 온보딩 레이어 이메일, 소셜, 패스키 등 친숙한 로그인으로 최초 가입 후 동일 계정으로 트랜잭션 생성 가능 핵심은 서명자 관리와 복구, 다중 서명자, 가스 스폰서십 등 계정 수명주기 운영을 일관된 UX로 제공하는 것

AGW 작동 방식

1단계 EOA 생성
- 사용자 로그인 방식을 통해 내부적으로 EOA 생성
2단계 스마트 컨트랙트 지갑 배포
- 배포 초기화 시 1단계 EOA를 승인된 서명자로 등록
이후 단계
- 서명자 추가·삭제, 패스키 기반 서명자 등록, 모듈 확장 등 계정 운영 기능 사용

스마트 컨트랙트 지갑은 네이티브 1급 시민으로 동작하며, 기본 곡선인 secp256k1 중심 운영 권장 패스키 확장 시 secp256r1 서명자 지원 가능, EIP-712 기반 서명 검증 로직 조합 권장

스마트 지갑 기능 모듈 예

복구 모듈
- 이메일 복구, 가디언 복구 등 키 분실 시 계정 복원 경로 제공
페이마스터 연동
- 트랜잭션 가스비 후원, 특정 토큰 지불 라우팅 구성
다중 서명자
- 역할 기반 서명 정책, 임계값 승인 정책 확장
패스키 지원
- FIDO 기반 기기 서명자를 지갑에 연결해 무서버 키 경험 제공

주의 사항과 트레이드오프

데이터 가용성 비용
- 블롭 가격은 네트워크 수요에 따라 변동, 배치 크기와 커밋 주기 최적화 필요
증명 대기 시간
- 증명 생성은 계산 집약적, 하드웨어와 회로 최적화 상태에 따라 지연 발생 가능
- 사용자 응답은 즉시성 확보 가능하나 L1 최종성은 증명 완료 이후 확보
시퀀서 검열 리스크
- 단일 시퀀서 운영 시 트랜잭션 포함 지연 가능성 존재
- 추후 분산화 로드맵, 포크 선택 규칙, 포스 인클루전 메커니즘 고려 필요
브리징과 메시징 안전성
- L1 확정 전 교차체인 메시지 사용 시 미확정 리스크 존재
- 지연 큐, 취소·재시도 정책, 상태 증명 기반 수령 조건 명시 필요
페이마스터 남용 방지
- 한도, 속도 제한, 수신자·함수 화이트리스트 운용
- 토큰 기반 가스 지불은 환산 레이트 변동과 유동성 부족 문제 고려
Nonce 경쟁과 재진행
- 중복 제출 방지, 재전송 정책, minNonce 관리 정책 표준화 필요

간단 예시와 실무 팁

JSON-RPC 제출 시 from을 스마트 컨트랙트 계정 주소로 지정해 계정 자체 검증 로직 구동
검증 단계에서 nonce 소비를 먼저 처리해 재진입·중복 실행 방지
EIP-712 타입 데이터 서명 사용으로 서명 범위와 목적을 명확히 표현
부트로더 전용 함수는 onlyBootloader로 차단, 외부 호출 경로 executeTransactionFromOutside를 별도 제어
L1 상호작용은 commit → prove → execute 순서 준수, 운영 관점에서 배치 커밋 지표와 증명 큐 길이를 모니터링

운영 베스트 프랙티스

배치 정책
- 수요에 따른 동적 배치 크기와 커밋 주기 조정, 블롭 단가와 증명 대기 시간의 균형 추구
가시성 확보
- 시퀀서 지연, 증명 생성 시간, 실패율, 큐 길이, L1 가스 단가, 블롭 단가 대시보드화
계정 추상화 보안
- validateTransaction에서 호출자·서명·정책 일관성 검증, 실패 시 명시적 에러 코드 반환
- 페이마스터 입력 파싱과 예산 검사 철저, 사후 훅에서 외부 호출 시 재진입 방지
릴리즈 전략
- 테스트넷에서 계정·페이마스터·브리징 경로를 통합 리허설, 가스 상한과 오류 복구 시나리오 검증
회로와 증명 백엔드
- 회로 업데이트는 롤링 업그레이드 전략 채택, 검증 키 교체와 컨트랙트 버전 호환성 체크리스트 운영

마무리

Abstract는 ZK Rollup과 EIP-4844를 결합해 확장성과 비용 효율을 확보하고, 네이티브 계정 추상화로 개발자와 사용자의 상호작용을 단순화하는 접근을 취함 시퀀서·증명 파이프라인·L1 계약 간 경계를 명확히 하고, 계정 추상화와 페이마스터 정책을 보안 우선으로 설계하면 운영 안정성을 크게 높일 수 있음 이 문서의 개념과 베스트 프랙티스를 기준으로 트랜잭션 수명주기, 지갑 모듈, 데이터 가용성 튜닝을 체계적으로 검토할 것을 권장함

개요#

배경과 목적#

핵심 개념#

동작 원리와 구조#

트랜잭션 수명주기 개요#

L1 상호작용 단계#

구성 요소#

네이티브 계정 추상화#

트랜잭션 플로우#

스마트 컨트랙트 지갑 설계 포인트#

Nonce 관리#

서명 검증과 EIP-1271#

Paymaster 개념#

AGW(Abstract Global Wallet) 개요#

AGW 작동 방식#

스마트 지갑 기능 모듈 예#

주의 사항과 트레이드오프#

간단 예시와 실무 팁#

운영 베스트 프랙티스#

마무리#

참고자료#

개요