Starknet 스마트 계약 모델과 네이티브 AA 해석: 독보적인 기술 거장
저자: Shew & Faust, 극객 web3
자문: CryptoNerdCn, 스타크넷 생태계 핵심 개발자, 브라우저 기반 카이로 개발 플랫폼 WASM Cairo 창시자
요약
스타크넷의 주요 기술적 특징으로는 ZK 증명 생성에 유리한 카이로 언어, 네이티브 수준의 AA(계정 추상화), 비즈니스 로직과 상태 저장을 분리하는 스마트 계약 모델이 있다.
카이로는 범용 ZK 언어로서, 스타크넷에서 스마트 계약을 구현할 수도 있고 전통적인 애플리케이션 개발에도 사용할 수 있으며, 컴파일 과정에서 중간 언어인 시에라(Sierra)를 도입함으로써 카이로가 자주 반복 업데이트되더라도 최하위 바이트코드는 변경하지 않고 변화를 중간 언어에만 반영할 수 있다. 또한 카이로 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조가 포함되어 있다.
스타크넷 스마트 계약은 비즈니스 로직과 상태 데이터를 별도로 저장한다. EVM 체인과 달리 카이로 계약 배포는 "컴파일, 선언, 배포" 세 단계를 거친다. 비즈니스 로직은 Contract class에 선언되며, 상태 데이터를 포함한 Contract 인스턴스는 이 class와 연결되고 후자가 포함한 코드를 호출할 수 있다.
스타크넷의 이러한 스마트 계약 모델은 코드 재사용, 계약 상태 재사용, 저장 계층화, 쓰레기 계약 탐지에 유리하며, 저장 임대제 및 트랜잭션 병렬 처리의 실현에도 긍정적이다. 후자는 아직 도입되지 않았지만, 카이로 스마트 계약 아키텍처는 이를 위한 "필수 조건"을 마련하고 있다.
스타크넷 체인에는 스마트 계약 계정만 존재하고 EOA 계정은 없다. 즉, 처음부터 네이티브 수준의 AA 계정 추상화를 지원한다. 그들의 AA 방식은 ERC-4337의 일부 개념을 흡수하여 사용자가 고도로 맞춤화된 트랜잭션 처리 방안을 선택할 수 있도록 한다. 잠재적인 공격 상황을 방지하기 위해 스타크넷은 다양한 대응 조치를 취하며, AA 생태계에 중요한 탐색을 제공하고 있다.
본문
스타크넷이 토큰을 발행한 이후, STRK는 이더리움 관측자들에게 점점 더 중요한 요소 중 하나가 되었다. 오랫동안 "독특함", "사용자 경험 무시"로 알려진 이더리움 레이어2의 스타는 마치 세상과 다투지 않는 은거자처럼, EVM 호환성이 지배하는 레이어2 생태계 속에서 자신만의 작은 영토를 조용히 일구고 있다.
너무나 사용자를 소홀히 하여 디스코드에 '전자 거지' 채널까지 공개적으로 개설하면서, 스타크넷은 일시적으로 에어드랍 농장꾼들로부터 비난을 받았다. '비인간적'이라는 비판을 받으며 기술적 역량이 순식간에 '전혀 가치 없게' 여겨졌고, 마치 UX와 부의 창출 효과만이 전부인 것처럼 느껴졌다. 『금각사』의 한 문장, "이해받지 못하는 것이 나의 유일한 자랑"은 마치 스타크넷의 자화상 같다.
그러나 이런 잡다한 이야기들을 제쳐두고, 순수하게 코드 극단주의자들의 '기술적 취향'에서 출발하면, ZK 롤업의 선구자 중 하나인 스타크넷과 스타크엑스(StarkEx)는 거의 카이로 애호가들에게 보물과 같으며, 어떤 웹3 게임 개발자들 사이에서는 스타크넷과 카이로가 웹3의 전부이며, 솔리디티나 무브(Move)는 그것을 따라올 수 없다고 생각한다. 현재 '기술 극단주의자'와 '사용자' 사이에 존재하는 가장 큰 격차는 사실 사람들이 스타크넷을 제대로 이해하지 못하는 데서 기인한다.
블록체인 기술에 대한 관심과 탐구심, 그리고 스타크넷의 가치 발견을 바탕으로, 본 저자는 스타크넷의 스마트 계약 모델과 네이티브 AA를 중심으로 그 기술 방안과 메커니즘 설계를 간략히 정리하여, 더 많은 사람들에게 스타크넷의 기술적 특성을 소개하고, 이 '이해받지 못하는 독보적인 행보를 걷는 자'를 알리고자 한다.
카이로 언어 초보자 안내
아래에서는 스타크넷의 스마트 계약 모델과 네이티브 계정 추상화에 집중하여 스타크넷이 어떻게 네이티브 AA를 실현하는지 설명하겠다. 이 글을 읽고 나면 왜 스타크넷에서 서로 다른 지갑의 시드 구문(seed phrase)을 혼용할 수 없는지도 이해할 수 있을 것이다.
그러나 네이티브 계정 추상화를 소개하기 전에, 먼저 스타크넷이 독자적으로 개발한 카이로 언어에 대해 알아보자. 카이로의 발전 과정에서 초기 버전인 카이로0과 이후의 현대 버전이 등장했다. 카이로의 현대 버전은 전체 문법이 러스트(Rust)와 유사하며, 실제로는 범용 ZK 언어이다. 스타크넷에서 스마트 계약을 작성하는 것 외에도 일반 애플리케이션 개발에도 사용할 수 있다.
예를 들어 카이로 언어로 ZK 신원 인증 시스템을 개발할 수 있으며, 이 프로그램은 자체 서버에서 실행 가능하고 스타크넷 네트워크에 의존할 필요가 없다. 검증 가능한 컴퓨팅 속성을 필요로 하는 모든 프로그램은 카이로 언어로 구현할 수 있다고 할 수 있다. 그리고 카이로는 현재 가장 ZK 증명 생성에 적합한 프로그래밍 언어일 가능성이 크다.
컴파일 과정을 보면, 카이로는 중간 언어 기반의 컴파일 방법을 사용한다. 아래 그림에서 시에라(Sierra)는 카이로 언어 컴파일 과정의 중간 형태(IR)이며, 이는 다시 CASM이라 불리는 하위 수준의 이진 코드 형태로 컴파일된다. CASM은 스타크넷 노드 장치에서 직접 실행된다.
시에라를 중간 형태로 도입함으로써 카이로 언어에 새로운 기능을 추가하기 쉬워지며, 대부분의 경우 시에라라는 중간 언어에서만 수정하면 되고, 하위 수준의 CASM 코드를 직접 변경할 필요가 없다. 이는 많은 번거로움을 줄여주며, 스타크넷 노드 클라이언트가 빈번하게 업데이트될 필요가 없게 된다. 이렇게 함으로써 스타크넷 하위 로직을 변경하지 않으면서도 카이로 언어의 빈번한 반복 업데이트를 실현할 수 있다. 또한 카이로 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조가 포함되어 있다.
카이로의 또 다른 혁신으로는 '카이로 네이티브(Cairo Native)'라는 이론적 방안이 있는데, 이는 카이로를 다양한 하드웨어 장치에 맞는 하위 기계 코드로 컴파일하는 것을 목표로 한다. 스타크넷 노드가 스마트 계약을 실행할 때 카이로VM 가상 머신에 의존하지 않게 되어 코드 실행 속도를 크게 향상시킬 수 있다. [현재는 이론 단계이며 실제 적용되지 않음]
스타크넷 스마트 계약 모델: 코드 로직과 상태 저장의 분리
EVM 호환 체인과 달리 스타크넷은 스마트 계약 시스템 설계에서 획기적인 혁신을 이루었으며, 이러한 혁신은 상당 부분 네이티브 AA와 미래에 도입될 병렬 트랜잭션 기능을 위한 준비이다. 여기서 기억해야 할 것은 이더리움 등의 전통 공공 블록체인에서 스마트 계약 배포는 일반적으로 "컴파일 후 배포" 방식을 따르며, ETH 스마트 계약을 예로 들면:
1. 개발자가 로컬에서 스마트 계약을 작성한 후, 편집기를 통해 솔리디티 프로그램을 EVM 바이트코드로 컴파일하여 EVM이 직접 이해하고 처리할 수 있게 한다.
2. 개발자가 스마트 계약 배포 트랜잭션 요청을 보내, 컴파일된 EVM 바이트코드를 이더리움 체인에 배포한다.
(이미지 출처: not-satoshi.com)
스타크넷의 스마트 계약도 "먼저 컴파일 후 배포"하는 아이디어를 따른다. 스마트 계약은 카이로VM이 지원하는 CASM 바이트코드 형식으로 체인에 배포되지만, 스마트 계약의 호출 방식과 상태 저장 모델 면에서 스타크넷은 EVM 호환 체인과 큰 차이를 보인다.
정확히 말하면, 이더리움 스마트 계약 = 비즈니스 로직 + 상태 정보이다. 예를 들어 USDT 계약은 Transfer, Approval 등의 일반 함수 기능을 구현할 뿐 아니라, 모든 USDT 보유자의 자산 상태를 저장한다. 코드와 상태가 결합되어 있어 여러 가지 문제를 야기한다. 먼저 DAPP 계약 업그레이드와 상태 마이그레이션이 어려우며, 트랜잭션의 병렬 처리에도 불리하다. 이는 무거운 기술적 부담이다.
이에 대해 스타크넷은 상태 저장 방식을 개선했다. 스마트 계약 구현 방안에서 DAPP의 비즈니스 로직과 자산 상태를 완전히 분리하여 각각 다른 위치에 저장한다. 이렇게 하는 장점은 명백하다. 우선 시스템이 중복되거나 불필요한 코드 배포 여부를 더 빠르게 판단할 수 있다. 원리는 다음과 같다.
이더리움 스마트 계약 = 비즈니스 로직 + 상태 데이터라고 할 때, 몇 개의 계약이 비즈니스 로직 부분은 동일하지만 상태 데이터가 다르면, 이들 계약의 해시도 서로 다르므로 시스템이 이러한 계약들이 중복되었는지, '쓰레기 계약'이 존재하는지 판단하기 어렵다.
반면 스타크넷 방안에서는 코드 부분과 상태 데이터를 직접 분리함으로써, 시스템은 코드 부분의 해시를 기반으로 동일한 코드가 여러 번 배포되었는지를 쉽게 판단할 수 있다. 왜냐하면 그들의 해시 값이 동일하기 때문이다. 이를 통해 중복 코드 배포를 억제하고 스타크넷 노드의 저장 공간을 절약할 수 있다.
스타크넷의 스마트 계약 시스템에서 계약의 배포와 사용은 "컴파일, 선언, 배포" 세 단계로 나뉜다. 자산 발행자가 카이로 계약을 배포하려면, 먼저 자신의 장치 로컬에서 작성한 카이로 코드를 시에라(Sierra) 및 하위 바이트코드 CASM 형식으로 컴파일해야 한다.
다음으로, 계약 배포자는 '선언(declare)' 트랜잭션을 발행하여 계약의 CASM 바이트코드와 시에라 중간 코드를 체인에 배포해야 하며, 이를 Contract Class라 부른다.
(이미지 출처: 스타크넷 공식 홈페이지)
이후 해당 자산 계약에서 정의된 함수 기능을 사용하려면 DAPP 프론트엔드를 통해 'deploy' 트랜잭션을 발행하여 Contract Class와 연결된 Contract 인스턴스를 배포할 수 있다. 이 인스턴스에는 자산 상태가 저장된다. 이후 사용자는 Contract Class 내 함수 기능을 호출하여 Contract 인스턴스의 상태를 변경할 수 있다.
객체지향 프로그래밍을 아는 사람이라면 스타크넷의 Class와 Instance가 무엇을 의미하는지 쉽게 이해할 수 있을 것이다. 개발자가 선언한 Contract Class는 스마트 계약의 비즈니스 로직만 포함하며, 누구나 호출할 수 있는 함수 기능이지만 실제 자산 상태는 없으므로 '자산 실체'를 직접 구현하지 않는다. 즉 '영혼'만 있고 '육체'는 없다.
반면 사용자가 구체적인 Contract 인스턴스를 배포하면 자산은 '실체화'된다. 자산 '실체'의 상태를 변경하려면, 예를 들어 자신의 토큰을 타인에게 이전하려면, Contract Class에 미리 작성된 함수 기능을 직접 호출할 수 있다. 이 과정은 전통적인 객체지향 프로그래밍 언어의 '인스턴스화'와 유사하지만 완전히 동일하지는 않다.
스마트 계약이 Class와 인스턴스로 분리됨으로써 비즈니스 로직과 상태 데이터가 분리되어 스타크넷에 다음과 같은 특성을 가져다준다.
1. 저장 계층화와 '저장 임대제' 실현에 유리
'저장 계층화'란 개발자가 자신의 요구에 따라 데이터를 사용자 정의 위치, 예를 들어 스타크넷 체인 외부에 저장할 수 있다는 것을 의미한다. 스타크넷은 세레스티아(Celestia) 등의 DA 계층과 호환할 예정이며, DAPP 개발자는 데이터를 이러한 제3자 DA 계층에 저장할 수 있다. 예를 들어 게임은 가장 중요한 자산 데이터는 스타크넷 메인넷에 저장하고, 기타 데이터는 세레스티아 등의 오프체인 DA 계층에 저장할 수 있다. 보안 요구에 따라 DA 계층을 맞춤형으로 선택하는 이 방안을 스타크넷은 "볼리션(Volition)"이라 명명했다.
'저장 임대제'란 개인이 차지한 저장 공간에 대해 지속적으로 요금을 지불해야 한다는 것을 의미한다. 당신이 체인상에서 차지한 공간이 얼마나 되는지에 따라 이론적으로 지속적으로 임대료를 지불해야 한다.
이더리움 스마트 계약 모델에서는 계약 소유권이 불분명하여 ERC-20 계약의 '임대료'를 배포자가 지불해야 할지, 자산 보유자가 지불해야 할지 판단하기 어렵다. 저장 임대 기능 도입이 늦어지고 배포 시 배포자에게 일회성 비용만 부과하는 저장 요금 모델은 합리적이지 않다.
반면 스타크넷과 Sui, CKB, Solana의 스마트 계약 모델에서는 스마트 계약의 소유권 구분이 더 명확하여 저장 요금 징수가 용이하다. [현재 스타크넷은 저장 임대제를 직접 도입하지 않았지만 향후 실현할 예정]
2. 진정한 코드 재사용 실현, 쓰레기 계약 배포 감소
우리는 범용 토큰 계약을 class로 선언하여 체인에 저장한 후 모두가 이 class의 함수를 호출하여 자신만의 토큰 인스턴스를 배포할 수 있다. 또한 계약은 class 내 코드를 직접 호출할 수 있으므로 솔리디티의 Library 함수 라이브러리와 유사한 효과를 얻을 수 있다.
또한 스타크넷의 이러한 스마트 계약 모델은 '쓰레기 계약' 탐지에 도움이 된다. 앞서 이에 대해 설명했다. 코드 재사용과 쓰레기 계약 탐지를 지원함으로써 스타크넷은 체인에 올라가는 데이터 양을 크게 줄이고 노드의 저장 부담을 최대한 경감할 수 있다.
3. 진정한 계약 '상태' 재사용
블록체인 상의 계약 업그레이드는 주로 비즈니스 로직 변경과 관련된다. 스타크넷 환경에서 스마트 계약의 비즈니스 로직과 자산 상태는 본질적으로 분리되어 있으므로, 계약 인스턴스가 연결된 계약 유형 class를 변경함으로써 비즈니스 로직 업그레이드를 완료할 수 있으며, 자산 상태를 새 위치로 마이그레이션할 필요가 없다. 이 계약 업그레이드 형태는 이더리움보다 더 철저하고 더 원시적이다.
반면 이더리움 계약이 비즈니스 로직을 변경하려면 종종 비즈니스 로직을 프록시 계약에 '외주'하여 의존하는 프록시 계약을 변경함으로써 주계약의 비즈니스 로직을 변경하지만, 이 방식은 간결하지 못하고 '비원시적'이다.
(이미지 출처: wtf Academy)
어떤 상황에서는 기존 이더리움 계약이 완전히 폐기되면 내부 자산 상태를 새 위치로 직접 이전할 수 없어 매우 번거롭다. 반면 카이로 계약은 상태를 이전할 필요 없이 기존 상태를 바로 '재사용'할 수 있다.
4. 트랜잭션 병렬 처리에 유리
다양한 트랜잭션 명령의 병렬 처리 가능성을 최대한 높이기 위해서는 서로 다른 사람들의 자산 상태를 분산 저장하는 것이 필수적이다. 이것은 비트코인, CKB, Sui에서 두드러진다. 그리고 이러한 목표를 위한 전제 조건은 스마트 계약의 비즈니스 로직과 자산 상태 데이터를 분리하는 것이다. 스타크넷은 아직 트랜잭션 병렬 처리를 위한 심층적인 기술 구현을 하지 않았지만, 미래에 병렬 트랜잭션을 중요한 목표로 삼을 예정이다.
스타크넷의 네이티브 AA와 계정 계약 배포
사실所谓 계정 추상화(AA)는 이더리움 커뮤니티가 만들어낸 독특한 개념이다. 많은 신규 공공 블록체인에서는 EOA 계정과 스마트 계약 계정의 구분이 없으며, 처음부터 이더리움식 계정 체계의 함정을 피했다. 예를 들어 이더리움 설정 하에서는 EOA 계정 소유자가 체인에 ETH가 있어야 트랜잭션을 시작할 수 있으며, 다양한 신원 인증 방식을 직접 선택할 수 없고, 맞춤형 지불 로직을 추가하는 것도 매우 번거롭다. 심지어 누군가는 이더리움의 이러한 계정 설계가 거의 반인류적이라고 생각하기까지 한다.
스타크넷이나 zkSync Era 등 '네이티브 AA'를 강조하는 체인을 살펴보면 명백한 차이점을 관찰할 수 있다. 먼저 스타크넷과 zkSync Era는 계정 유형을 통합하여 체인에는 스마트 계약 계정만 존재하고, 처음부터 EOA 계정이라는 개념이 없다(zkSync Era는 사용자가 새로 생성한 계정에 기본적으로 일련의 계약 코드를 배포하여 이더리움 EOA 계정의 특징을 시뮬레이션함으로써 메타마스크와의 호환을 쉽게 만든다).
스타크넷은 메타마스크 등의 이더리움 주변 시설과 직접 호환하는 것을 고려하지 않았으며, 사용자가 처음 스타크넷 지갑을 사용할 때 전용 계약 계정이 자동으로 배포된다. 즉 앞서 언급한 계약 인스턴스를 배포하는 것이다. 이 계약 인스턴스는 지갑 프로젝트팀이 사전에 배포한 계약 class와 연결되며, class 내 미리 작성된 일부 기능을 직접 호출할 수 있다.
다음은 흥미로운 주제를 다룰 것이다. STRK 에어드랍을 받을 때 많은 사람이 아르젠티나(Argent)와 브라보스(Braavos) 지갑이 서로 호환되지 않는다는 것을 발견했다. 아르젠티나의 시드 구문을 브라보스에 가져오면 해당 계정을 내보낼 수 없다. 이는 아르젠티나와 브라보스가 서로 다른 계정 생성 계산 방식을 채택했기 때문에 동일한 시드 구문으로 생성된 계정 주소가 다르기 때문이다.
구체적으로 스타크넷에서는 새로 배포된 계약 주소를 결정적인 알고리즘으로 도출할 수 있으며, 다음 공식을 사용한다.
위 공식에서 pedersen()은 ZK 시스템에서 쉽게 사용할 수 있는 해시 알고리즘이며, 계정 생성 과정은 pedersen 함수에 몇 가지 특수 매개변수를 입력하여 해당 해시를 생성하는 것으로, 이 해시가 생성된 계정 주소이다.
위 이미지에는 스타크넷이 '새 계약 주소'를 생성할 때 사용하는 매개변수가 표시되어 있다. deployer_address는 '계약 배포자'의 주소를 나타내며, 이 매개변수는 비어 있을 수 있다. 즉, 스타크넷 계약 계정이 없더라도 새로운 계약을 배포할 수 있다.
salt는 계약 주소 계산을 위한 솔트(salt) 값으로, 간단히 말해 난수이다. 이 변수는 실제로 계약 주소 중복을 방지하기 위해 도입되었다. class_hash는 앞서 소개한 바와 같이 계약 인스턴스가 연결된 class의 해시값이다. constructor_calldata_hash는 계약 초기화 매개변수의 해시를 의미한다.
위 공식을 기반으로 사용자는 계약이 체인에 배포되기 전에 생성될 계약 주소를 미리 계산할 수 있다. 스타크넷은 사용자가 사전에 스타크넷 계정을 보유하지 않더라도 직접 계약을 배포할 수 있도록 허용하며, 절차는 다음과 같다.
1. 사용자는 자신이 배포하려는 계약 인스턴스가 어떤 계약 class와 연결되어야 하는지 결정하고, 해당 class의 해시 값을 초기화 매개변수 중 하나로 하며 salt를 계산하여 생성될 계약 주소를 알게 된다.
2. 사용자는 계약을 어디에 배포할지 알고 나서 먼저 해당 주소로 일정량의 ETH를 전송하여 계약 배포 비용으로 한다. 일반적으로 이 부분의 ETH는 L1에서 크로스체인 브릿지를 통해 스타크넷 네트워크로 옮긴다.
3. 사용자는 계약 배포 트랜잭션 요청을 시작한다.
사실 모든 스타크넷 계정은 위 절차를 통해 배포되지만, 대부분의 지갑은 이 세부 사항을 숨기고 있어 사용자는 그 과정을 전혀 느끼지 못한다. 마치 ETH를 입금한 후 계약 계정이 자동으로 배포되는 것처럼 보인다.
이러한 방안은 일부 호환성 문제를 야기한다. 서로 다른 지갑이 계정 주소를 생성할 때 결과가 일치하지 않기 때문이다. 다음 조건을 모두 충족하는 지갑만 혼용할 수 있다.
-
지갑이 사용하는 개인키에서 공개키를 파생시키는 알고리즘과 서명 알고리즘이 동일해야 한다.
-
지갑의 salt 계산 프로세스가 동일해야 한다.
-
지갑의 스마트 계약 class가 구현 세부사항에서 근본적인 차이가 없어야 한다.
앞서 언급한 사례에서 아르젠티나와 브라보스는 모두 ECDSA 서명 알고리즘을 사용하지만, 양측의 salt 계산 방법이 다르므로 동일한 시드 구문으로 생성된 계정 주소가 서로 다르다.
다시 계정 추상화 주제로 돌아가자. 스타크넷과 zkSync Era는 트랜잭션 처리 과정에서 신원 인증(디지털 서명 검증), 가스비 지불 등 핵심 로직을 모두 '체인 하위 수준' 밖으로 옮겼다. 사용자는 자신의 계정에서 이러한 로직의 구현 세부사항을 사용자 정의할 수 있다.
예를 들어 스타크넷 스마트 계약 계정에 전용 디지털 서명 검증 함수를 배포할 수 있다. 스타크넷 노드가 사용자가 시작한 트랜잭션을 수신하면, 체인상 계정에 사용자 정의된 일련의 트랜잭션 처리 로직을 호출한다. 이렇게 하면 훨씬 더 유연하다.
반면 이더리움 설계에서는 신원 인증(디지털 서명) 등의 로직이 노드 클라이언트 코드에 하드코딩되어 있어 계정 기능의 사용자 정의를 원시적으로 지원하지 않는다.
(스타크넷 아키텍트가 제시한 네이티브 AA 방안 도식. 트랜잭션 검증과 가스비 자격 검증이 모두 체인상 계약으로 이전되어 처리되며, 체인 하위 수준의 가상 머신은 사용자 정의 또는 지정된 함수를 호출할 수 있음)
zkSync Era와 스타크넷 공식 인사들의 말에 따르면, 이 계정 기능 모듈화 접근법은 EIP-4337에서 영감을 얻었다. 그러나 다른 점은 zkSync와 스타크넷이 처음부터 계정 유형을 통합하고 거래 유형을 통일하며 통합된 입구를 통해 모든 거래를 수신하고 처리한다는 점이다. 반면 이더리움은 역사적 부채가 있으며, 재단은 하드포크와 같은 강력한 반복 방안을 최대한 피하고자 하므로 EIP-4337과 같은 '우회로' 방안을 지지했지만, 이로 인해 EOA 계정과 4337 방안이 각각 독립적인 거래 처리 프로세스를 사용하게 되어 어색하고 중복되어 네이티브 AA만큼 유연하지 못하다.
(이미지 출처: ArgentWallet)
그러나 현재 스타크넷의 네이티브 계정 추상화는 완전한 성숙 단계에 도달하지 못했다. 실천 진행 상황을 보면, 스타크넷의 AA 계정은 서명 검증 알고리즘의 사용자 정의를 실현했지만, 수수료 지불의 사용자 정의 측면에서는 현재 실제로 ETH와 STRK로 가스비를 납부하는 것만 지원하고, 제3자 대납 가스는 아직 지원하지 않는다. 따라서 스타크넷의 네이티브 AA 진척도는 "이론적 방안은 기본적으로 성숙했지만, 실천 방안은 여전히 추진 중"이라고 할 수 있다.
스타크넷 내에는 스마트 계약 계정만 존재하므로 트랜잭션의 전체 프로세스는 계정 스마트 계약의 영향을 고려한다. 먼저 트랜잭션이 스타크넷 노드의 메모리풀(Mempool)에 수신되면 검증을 거치며, 검증 단계는 다음과 같다.
-
거래의 디지털 서명이 올바른지 확인하며, 이때 거래 발신자 계정의 사용자 정의 서명 검증 함수를 호출한다.
-
거래 발신자의 계정 잔액이 가스비를 지불할 수 있는지 확인한다.
여기서 주의할 점은, 계정 스마트 계약의 사용자 정의 서명 검증 함수를 사용한다는 것은 공격 시나리오가 존재한다는 것을 의미한다. 메모리풀이 새로 들어온 트랜잭션의 서명을 검증할 때 가스비를 청구하지 않기 때문이다(직접 가스비를 청구하면 더 심각한 공격 시나리오가 발생할 수 있다). 악의적인 사용자는 먼저 자신의 계정 계약에서 매우 복잡한 서명 검증 함수를 사용자 정의한 후 대량의 트랜잭션을 시작하여 검증 시마다 사용자 정의된 복잡한 서명 검증 함수를 호출하도록 하면 노드의 계산 자원을 고갈시킬 수 있다.
이런 상황을 방지하기 위해 스타크넷은 다음과 같은 제한을 두었다.
-
개별 사용자는 단위 시간 내에 발행할 수 있는 트랜잭션 수에 상한이 있다.
-
스타크넷 계정 계약에서 사용자 정의한 서명 검증 함수는 복잡도 제한이 있으며, 너무 복잡한 서명 검증 함수는 실행되지 않는다. 스타크넷은 서명 검증 함수의 가스 소비 상한을 제한하며, 가스 소비량이 너무 높으면 거래를 거부한다. 또한 계정 계약 내 서명 검증 함수가 다른 계약을 호출하는 것도 허용하지 않는다.
스타크넷 트랜잭션 흐름도는 다음과 같다.
주목할 점은, 트랜잭션 검증 프로세스를 더욱 가속화하기 위해 스타크넷 노드 클라이언트는 Braavos 및 Argent 지갑의 서명 검증 알고리즘을 직접 구현했다는 점이다. 노드가 거래가 이 두 대표적인 스타크넷 지갑에서 생성되었음을 감지하면 클라이언트에 내장된 Braavos/Argent 서명 알고리즘을 호출하여 캐시와 유사한 사고방식으로 트랜잭션 검증 시간을 단축할 수 있다.
정렬기(Orderer)의 검증을 통과한 후(정렬기의 검증 단계는 메모리풀 검증보다 훨씬 심층적임), 정렬기는 메모리풀에서 온 트랜잭션을 패키징하여 ZK 증명 생성기에 전달한다. 이 단계에 들어간 거래는 실패하더라도 가스비를 부과한다.
그러나 스타크넷의 역사를 알고 있는 독자라면 초기 스타크넷은 실행에 실패한 거래에 대해 수수료를 부과하지 않았다는 점을 알게 될 것이다. 가장 흔한 거래 실패 사례는 사용자가 1ETH만 보유하고 있지만 10ETH를 송금하려는 경우로, 이러한 거래는 명백히 논리적 오류가 있으며 결국 반드시 실패하지만, 구체적인 실행 전에는 그 결과를 아무도 알 수 없다.
그러나 스타크넷은 과거에 이러한 실패 거래에 대해 수수료를 부과하지 않았다. 이 무비용 오류 거래는 스타크넷 노드의 계산 자원을 낭비하며, DDOS 공격 시나리오를 유발할 수 있다. 겉보기에 오류 거래에 수수료를 부과하는 것은 쉬워 보이지만 실제로는 매우 복잡하다. 스타크넷은 실패한 거래의 가스 수수료 징수 문제를 해결하기 위해 새로운 버전의 카이로1 언어를 출시했다.
우리 모두가 아는 바와 같이, ZK Proof는 유효성 증명이며, 실행에 실패한 거래의 결과는 무효이며 체인에 출력 결과를 남길 수 없다. 유효성 증명을 사용하여 어떤 명령이 무효로 실행되어 출력 결과를 생성하지 못함을 증명하려는 시도는 이상하게 들릴 뿐 아니라 실제로도 불가능하다. 그래서 과거 스타크넷은 증명을 생성할 때 출력 결과를 생성하지 못하는 실패 거래를 모두 제외했다.
나중에 스타크넷 팀은 더 현명한 해결책을 채택했다. 모든 트랜잭션 명령이 출력 결과를 생성하고 체인에 올릴 수 있도록 하는 새로운 계약 언어 카이로1을 개발한 것이다. 보기에는 모든 트랜잭션이 출력을 생성하므로 논리적 오류가 전혀 없는 것처럼 보이지만, 대부분의 경우 거래 실패는 일부 버그로 인해 명령 실행이 중단되기 때문이다.
거래가 절대 중단되지 않고 출력을 성공적으로 생성하게 하기는 어렵지만, 실제로는 매우 간단한 대체 방안이 있다. 논리적 오류로 인해 거래가 중단될 때에도 출력 결과를 생성하게 하는 것이다. 다만 이때 False 값을 반환하여 이 거래의 실행이 순조롭지 않았음을 알릴 수 있다.
하지만 주의할 점은, False 값을 반환한다는 것은 출력 결과를 반환한다는 것을 의미하므로, 카이로1에서는 명령에 논리적 오류가 있든 없든, 일시적으로 중단되든 말든 모두 출력 결과를 생성하고 체인에 올릴 수 있다는 것이다. 이 출력 결과는 올바를 수도 있고, False 오류 메시지일 수도 있다.
예를 들어 다음과 같은 코드 조각이 있다고 가정하자.
여기서 _balances::read(from) - amount는 하향 오버플로로 인해 오류가 발생할 수 있으며, 이로 인해 해당 트랜잭션 명령이 중단되고 실행이 중지되어 체인에 거래 결과를 남기지 않는다. 그러나 다음과 같은 형태로 수정하면 거래가 실패하더라도 여전히 출력 결과를 생성하여 체인에 저장되며, 순전히 감각적으로 보면 마치 모든 거래가 원활하게 체인에 거래 출력을 남기는 것처럼 보이고, 통일된 수수료 부과가 특히 합리적으로 느껴진다.
스타크넷 AA 계약 개요
본문 독자 중 일부가 프로그래밍 배경을 가지고 있을 가능성을 고려하여, 여기서 스타크넷의 계정 추상화 계약 인터페이스를 간략히 보여준다.
위 인터페이스에서 __validate_declare__는 사용자가 시작한 declare 거래의 검증에 사용되며, __validate__는 일반 거래의 검증에 사용되며 주로 사용자의 서명이 올바른지 확인한다. __execute__는 거래 실행에 사용된다. 우리는 스타크넷 계약 계정이 기본적으로 multicall, 즉 다중 호출을 지원한다는 것을 알 수 있다. 다중 호출은 일부 흥미로운 기능을 실현할 수 있다. 예를 들어 특정 DeFi 상호작용을 수행할 때 다음 세 건의 거래를 묶을 수 있다.
-
첫 번째 거래에서 토큰을 DeFi 계약에 위임
-
두 번째 거래에서 DeFi 계약 로직을 트리거
-
세 번째 거래에서 DeFi 계약에 대한 위임을 해제
물론 다중 호출은 원자성을 가지므로 일부 더 복잡한 용도가 있다. 예를 들어 특정 차익 거래를 실행하는 것 등이다.
결론
스타크넷의 주요 기술적 특징으로는 ZK 증명 생성에 유리한 카이로 언어, 네이티브 수준의 AA, 비즈니스 로직과 상태 저장을 분리하는 스마트 계약 모델이 있다.
카이로는 범용 ZK 언어로서 스타크넷에서 스마트 계약을 구현할 수도 있고 전통적인 애플리케이션 개발에도 사용할 수 있으며, 컴파일 과정에서 중간 언어인 시에라를 도입함으로써 카이로가 자주 반복 업데이트되더라도 최하위 바이트코드는 변경하지 않고 변화를 중간 언어에만 반영할 수 있다. 또한 카이로 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조가 포함되어 있다.
스타크넷 스마트 계약은 비즈니스 로직과 상태 데이터를 별도로 저장한다. EVM 체인과 달리 카이로 계약 배포는 "컴파일, 선언, 배포" 세 단계를 거치며, 비즈니스 로직은 Contract class에 선언되고, 상태 데이터를 포함한 Contract 인스턴스는 이 class와 연결되어 후자가 포함한 코드를 호출할 수 있다.
스타크넷의 이러한 스마트 계약 모델은 코드 재사용, 계약 상태 재사용, 저장 계층화, 쓰레기 계약 탐지에 유리하며, 저장 임대제와 트랜잭션 병렬 처리의 실현에도 긍정적이다. 후자는 아직 도입되지 않았지만, 카이로 스마트 계약 아키텍처는 이를 위한 "필수 조건"을 마련하고 있다.
스타크넷 체인에는 스마트 계약 계정만 존재하고 EOA 계정은 없다. 즉, 처음부터 네이티브 수준의 AA 계정 추상화를 지원한다. 그들의 AA 방식은 ERC-4337의 일부 개념을 흡수하여 사용자가 고도로 맞춤화된 트랜잭션 처리 방안을 선택할 수 있도록 한다. 잠재적인 공격 상황을 방지하기 위해 스타크넷은 다양한 대응 조치를 취하며, AA 생태계에 중요한 탐색을 제공하고 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
