스타크넷 스마트 컨트랙트 모델과 네이티브 AA: 매버릭 기술 거인

바이 셰우 & 파우스트, 긱웹3

추상

• 스타크넷의 가장 중요한 기술적 특징으로는 ZK 증명 생성을 용이하게 하는 카이로 언어, 네이티브 레벨 AA, 비즈니스 로직 및 상태 저장소 독립적인 지능형 계약 모델을 포함합니다.

• 카이로는 스타크넷에서 스마트 컨트랙트를 구현하는 데 사용할 수 있을 뿐만 아니라 보다 전통적인 애플리케이션 개발에도 사용할 수 있는 범용 ZK 언어이며, 컴파일 과정에서 시에라를 중간 언어로 도입하여 기본 바이트 코드를 변경할 필요 없이 카이로를 자주 반복할 수 있도록 합니다. 컴파일 과정에서 시에라를 중간 언어로 도입하여 기본 바이트 코드를 변경할 필요 없이 변경 사항을 중간 언어로 전달하기만 하면 카이로를 자주 반복할 수 있으며, 계정 추상화에 필요한 많은 기본 데이터 구조도 카이로의 표준 라이브러리에 포함되어 있습니다.

• 스타크넷 스마트 컨트랙트는 비즈니스 로직을 상태 데이터와 별도로 저장하며, EVM 체인과 달리 카이로 컨트랙트 배포는 "컴파일, 선언, 배포" 단계로 구성되며, 비즈니스 로직은 컴파일에서 선언됩니다. 비즈니스 로직은 컨트랙트 클래스에 선언되며, 상태 데이터를 포함하는 컨트랙트 인스턴스는 클래스와 연관되어 후자에 포함된 코드를 호출할 수 있습니다.

블록체인 기술에 대한 관심과 탐구욕, 그리고 스타크넷의 가치를 발견한 이 글의 저자는 스타크넷의 스마트 컨트랙트 모델과 네이티브 AA에서 출발하여 기술적 솔루션과 메커니즘 설계에 대해 간략하게 설명하면서 스타크넷의 기술 특징을 보여줍니다. 더 많은 사람들에게 스타크넷 기술의 특징을 보여줄 뿐만 아니라, '알려지지 않은 거물'인 스타크넷을 알리고자 합니다.

간단히 말해서 카이로

다음 글에서는 스타크넷의 스마트 컨트랙트 모델과 네이티브 계정 추상화에 초점을 맞추고, 스타크넷이 네이티브 AA를 구현하는 방법을 설명하겠습니다. 이 글을 읽고 나면 스타크넷에서 다른 지갑의 보조 기능을 혼합할 수 없는 이유도 이해할 수 있을 것입니다.

네이티브 계정 추상화를 소개하기 전에 스타크넷의 원래 카이로 언어에 대해 알아봅시다. 카이로의 개발 과정에서 카이로0이라는 초기 버전이 있었고, 이후 현대 버전이 나왔는데, 전체적인 구문은 러스트와 유사하며, 실제로는 스타크넷에서 스마트 컨트랙트를 작성하는 것 외에도 범용 애플리케이션 개발에도 사용할 수 있는 범용 ZK 언어입니다.

예를 들어, 스타크넷 네트워크에 의존하지 않고도 직접 구축한 서버에서 실행할 수 있는 카이로 언어로 ZK 인증 시스템을 개발할 수 있습니다. 검증 가능한 계산 속성이 필요한 모든 프로그램은 카이로 언어로 구현할 수 있습니다. 그리고 카이로는 아마도 ZK 증명을 생성하는 데 가장 유용한 프로그래밍 언어일 것입니다.

컴파일 프로세스 측면에서 Cairo는 다음 그림과 같이 중간 언어 기반 컴파일 방법을 사용합니다. 그림에서 시에라는 카이로 언어 컴파일 과정의 중간 형태(IR)이며, 이후 시에라는 스타크넷 노드 디바이스에서 직접 실행되는 CASM이라는 더 하위의 바이너리 코드 형태로 컴파일됩니다.

시에라를 중간 형태로 도입하면 카이로 언어에 새로운 기능을 추가하기 쉬워지며, 많은 경우 기본 CASM 코드를 직접 변경할 필요 없이 시에라를 중간 형태로 손질하는 것만으로도 가능합니다. 이렇게 하면 많은 수고를 덜 수 있으며, 스타크넷 노드 클라이언트를 자주 업데이트할 필요가 없습니다. 따라서 기본 스타크넷 로직을 변경하지 않고도 카이로 언어를 자주 반복할 수 있습니다. 또한 계정 추상화에 필요한 많은 기본 데이터 구조가 카이로의 표준 라이브러리에 통합되어 있습니다.

카이로의 다른 혁신으로는 카이로를 다양한 하드웨어 장치에 적용할 수 있는 기본 머신 코드로 컴파일하는 카이로 네이티브라는 이론적 솔루션이 있으며, 스타크넷 노드는 스마트 컨트랙트를 실행할 때 카이로VM 가상 머신에 의존하지 않아도 되므로 코드 실행 속도가 크게 향상될 수 있습니다. 코드 실행 속도[아직은 이론적인 단계이며, 실제 적용되지 않음]를 크게 향상시킬 수 있습니다.

이미지 src="https://img.jinse.cn/7189602_image3.png">

스타크넷 스마트 콘트랙트 모델: 코드 로직과 상태 저장소 분할

EVM 호환 체인과 달리. 스타크넷은 스마트 컨트랙트 시스템 설계에 있어 획기적인 혁신을 이루었으며, 이는 주로 네이티브 AA와 향후 온라인화될 병렬 거래 기능에 대비하기 위한 것입니다. 여기서 이더와 같은 전통적인 퍼블릭 체인에서 스마트 콘트랙트는 "컴파일 후 배포" 방식으로 배포되는 경우가 많다는 것을 알아야 하는데, 이더 스마트 콘트랙트를 예로 들면 다음과 같습니다.

1. 개발자가 로컬에서 스마트 콘트랙트를 작성한 후, 컴파일합니다. 개발자가 로컬에서 스마트 컨트랙트를 작성한 후, 솔리디티 프로그램을 편집기를 통해 EVM 바이트코드로 컴파일하여 EVM이 직접 이해하고 처리할 수 있도록 합니다.

2. 개발자는 스마트 컨트랙트를 배포하기 위해 트랜잭션 요청을 시작한 다음 컴파일된 EVM 바이트코드를 이더채널에 배포합니다.

(이미지 출처: not-. satoshi.com)

스타크넷의 스마트 컨트랙트도 "선 컴파일, 후 배포"라는 개념을 따르지만, 스마트 컨트랙트는 카이로VM이 지원하는 CASM 바이트코드 형태로 체인에 배포됩니다. 그러나 스마트 컨트랙트 호출과 상태 저장 모드 측면에서 스타크넷과 EVM 호환 체인은 큰 차이가 있습니다.

정확히 말하면, 이더 스마트 컨트랙트 = 비즈니스 로직 + 상태 정보 예를 들어 USDT의 컨트랙트는 전송, 승인 및 기타 일반적으로 사용되는 기능을 구현할 뿐만 아니라 USDT의 모든 보유자의 자산 상태를 저장하며,코드와 상태는 다음과 같습니다. 코드와 상태가 함께 결합되어 많은 문제를 야기하며, 우선 DAPP 계약 업그레이드 및 상태 마이그레이션에 도움이되지 않을뿐만 아니라 일종의 무거운 기술적 짐인 트랜잭션의 병렬 처리에도 도움이되지 않습니다.

이 점에서 스타크넷은 스마트 컨트랙트 구현 체계에서 상태 저장을 개선했으며, DAPP의 비즈니스 로직과 자산은 완전히 분리되어 있습니다. 스마트 컨트랙트 구현 프로그램에서 DAPP의 비즈니스 로직은 자산 상태와 완전히 분리되어 서로 다른 곳에 저장됩니다. 이렇게 함으로써 얻을 수 있는 이점은 첫째, 시스템에서 중복 또는 중복 코드 배포 여부를 더 빠르게 구분할 수 있다는 점입니다. 이더넷 스마트 컨트랙트 = 비즈니스 로직 + 상태 데이터 비즈니스 로직은 같지만 상태 데이터가 다른 여러 개의 컨트랙트가 있는 경우, 이러한 컨트랙트의 해시도 다르기 때문에 시스템에서 이러한 컨트랙트의 중복 여부와 "정크 컨트랙트" 여부를 구별하기 어렵습니다. 계약은 계약이 아니라 계약일 뿐입니다.

스타크넷의 솔루션에서는 코드와 상태 데이터가 직접 분리되어 있고, 코드의 해시가 동일하기 때문에 시스템에서 코드의 해시를 기반으로 동일한 코드가 여러 번 배포되었는지 여부를 보다 쉽게 구분할 수 있습니다. 이를 통해 반복적인 코드 배포 동작을 더 쉽게 중지하고 스타크넷 노드의 저장 공간을 절약할 수 있습니다.

스타크넷의 스마트 컨트랙트 시스템에서 컨트랙트의 배포와 사용은 "컴파일, 선언, 배포" 세 단계로 나뉩니다. 카이로 콘트랙트를 배포하려면, 첫 번째 단계는 자산 발행자가 작성한 카이로 코드를 디바이스에서 시에라 및 기본 바이트코드 CASM 형식으로 로컬 컴파일하는 것입니다.

그런 다음 컨트랙트 배포자는 "선언" 트랜잭션을 발행하여 컨트랙트의 CASM 바이트코드와 시에라 중간 코드를 체인에 컨트랙트 클래스로 배포합니다.

(이미지 출처: (이미지 출처: 스타크넷 공식 홈페이지)

이후, 자산 컨트랙트에 정의된 기능을 적용하고 싶다면 DAPP 프론트엔드를 통해 '배포' 트랜잭션을 시작하여 컨트랙트 클래스가 포함된 컨트랙트 클래스와 연결된 컨트랙트 인스턴스를 배포할 수 있습니다. 강함>을 포함하고 자산의 상태를 저장합니다. 이후 사용자는 컨트랙트 클래스의 함수를 호출하여 컨트랙트 인스턴스의 상태를 변경할 수 있습니다.

사실 객체지향 프로그래밍을 이해하는 사람이라면 누구나 스타크넷의 클래스와 인스턴스가 무엇을 나타내는지 쉽게 이해할 수 있을 것입니다. 개발자가 선언한 컨트랙트 클래스는 스마트 컨트랙트의 비즈니스 로직만 담고 있으며, 누구나 호출할 수 있는 함수의 일부이지만 자산의 실제 상태는 없으며, '자산 실체'를 직접 구현한 것이 아니라 '영혼'만 있을 뿐 '육체'는 존재하지 않습니다. 실제 자산 상태도 없고, "자산 실체"의 직접적인 구현도 없으며, "영혼"만 있을 뿐 "육체"는 존재하지 않습니다.

사용자가 특정 컨트랙트 인스턴스를 배포하면 자산이 "구체화"됩니다. 예를 들어 토큰을 다른 사람에게 양도하기 위해 자산 "실체"의 상태를 변경하려면 컨트랙트 클래스에 작성된 함수를 직접 호출하면 됩니다. 위 프로세스는 기존 객체 지향 프로그래밍 언어의 "인스턴스화"와 다소 유사합니다(동일하지는 않음).

스마트 컨트랙트가 클래스와 인스턴스로 분리된 후에는 인스턴스로 분리한 후, 비즈니스 로직과 상태 데이터를 분리하면 다음과 같은 기능이 스타크넷에 추가됩니다.

1. 스토리지 계층화 및 "스토리지 임대"

소위 스토리지 계층화는 개발자가 자신의 필요에 따라 데이터를 맞춤형 위치에 배치할 수 있다는 것을 의미합니다. 이른바 스토리지 계층화는 개발자가 필요에 따라 스타크넷 체인 아래 등 맞춤형 위치에 데이터를 저장할 수 있다는 의미로, 스타크넷은 셀레스티아와 같은 DA 계층과 호환될 준비가 되어 있으며, DAPP 개발자는 이러한 타사 DA 계층에 데이터를 저장할 수 있습니다. 예를 들어, 게임은 가장 중요한 자산 데이터를 메인 스타크넷 네트워크에 저장하고 나머지 데이터는 셀레스티아와 같은 오프체인 DA 레이어에 저장할 수 있습니다. 보안 요구 사항을 충족하기 위한 이러한 DA 계층의 커스터마이징을 스타크넷에서는 "볼리션"이라고 부릅니다.

소위 스토리지 임대 시스템은 모든 사람이 지속적으로 사용하는 스토리지 공간에 대한 비용을 지불해야 한다는 것을 의미합니다. 이론적으로는 온체인 공간을 차지하는 만큼 지속적으로 임대료를 지불해야 합니다.

"네이티브 AA"에 초점을 맞추고 있는 스타크넷이나 zk싱크에라와 같은 체인을 살펴보면 분명한 차이점을 발견할 수 있습니다: 첫째, 스타크넷과 zk싱크에라는 계정 유형을 통합하여 유형으로, 체인에 스마트 컨트랙트 계정만 있고 처음부터 EOA 계정과 같은 것은 없습니다 (zkSync Era는 사용자가 새로 생성한 계정에 이더리움 EOA 계정의 특성을 모방한 기본 컨트랙트 코드 세트를 배포하여 메타마스크와의 호환을 용이하게 합니다).

이미지 src="https://img.jinse.cn/7189607_image3.png">

스타크넷은 메타마스크와 같은 이더리움 주변기기와의 직접적인 호환성을 고려하지 않지만, 사용자가 처음 사용할 때 스타크넷 지갑이 자동으로 배포됩니다. 전용 컨트랙트 계정, 즉 앞서 언급한 컨트랙트 인스턴스를 배포하게 되는데, 이는 지갑 프로젝트에서 미리 배포한 컨트랙트 클래스와 연결되며, 클래스 내부에 작성된 일부 함수를 직접 호출할 수 있습니다.

이제 흥미로운 주제에 대해 이야기하겠습니다.많은 사람들이 STRK 에어드랍을 받을 때, 아르헨티나와 브라보스 지갑이 서로 호환되지 않는 것을 발견하고 아르헨티나의 보조 단어를 브라보스로 가져온 후 해당 계정을 내보낼 수 없다는 것을 알게 됩니다. 아르젠트와 브라보스는 서로 다른 계정 생성 계산 방법을 사용하기 때문에 동일한 니모닉에 대해 서로 다른 계정 주소가 생성되기 때문입니다.

특히, 스타크넷에서 새로 배포된 컨트랙트의 주소는 다음 공식을 사용하여 결정론적 알고리즘으로 도출할 수 있습니다:

위 공식의 pedersen()의 위의 공식은 ZK 시스템 해시 알고리즘에서 사용하기 쉬운 것으로, 실제로 계정을 생성하는 과정은 pedersen 함수에 몇 가지 특수 매개 변수를 입력하여 해당 해시를 생성하는 것이며, 이 해시는 생성된 계정 주소입니다.

위 이미지는 스타크넷이 "새 컨트랙트 주소"를 생성하는 데 사용하는 몇 가지 파라미터를 보여줍니다. deployer_address는 "컨트랙트 배포자"의 주소를 나타내며, 이 파라미터는 비어있을 수 있습니다. 이 파라미터는 비워둘 수 있으므로 사전에 스타크넷 컨트랙트 계정이 없더라도 새 컨트랙트를 배포할 수 있습니다.

salt는 컨트랙트의 주소를 계산하는 데 사용되는 소금으로, 단순히 난수입니다. class_hash는 앞서 설명한 것처럼 컨트랙트 인스턴스 클래스의 해시 값입니다. 그리고 생성자_콜데이터_해시는 컨트랙트 초기화 파라미터의 해시를 나타냅니다.

위 공식을 기반으로 사용자는 컨트랙트가 체인에 배포되기 전에 생성된 컨트랙트의 주소를 미리 계산할 수 있으며, 스타크넷에서는 사용자가 스타크넷 계정 없이 직접 컨트랙트를 배포할 수 있으며, 그 과정은 다음과 같습니다.

1. 사용자는 먼저 배포할 컨트랙트 인스턴스와 연결할 컨트랙트 클래스를 결정하고 클래스의 해시를 초기화 파라미터로 사용할 수 있습니다. 클래스 해시를 초기화 매개변수 중 하나로 사용하고 솔트를 계산하여 생성하는 컨트랙트의 주소를 알 수 있습니다.

2. 컨트랙트를 배포할 위치를 파악한 후 사용자는 먼저 일정 금액의 이더를 컨트랙트 배포 수수료로 해당 주소로 전송합니다. 일반적으로 이 이더리움은 크로스 체인 브리지를 통해 L1에서 스타크넷 네트워크로 건너가야 합니다.

3. 사용자가 컨트랙트 배포를 위한 트랜잭션 요청을 시작합니다.

사실 모든 스타크넷 계정은 위의 과정을 통해 배포되지만, 대부분의 지갑은 이에 대한 내용을 차단하고 있어 사용자는 마치 이더를 전송한 후 컨트랙트 계정이 배포되는 것처럼 이 과정을 전혀 인지하지 못합니다.

위 시나리오는 계정 주소를 생성할 때 지갑마다 일관되지 않은 결과를 생성하므로 호환성 문제가 발생할 수 있으므로 다음 조건을 충족하는 지갑만 혼합할 수 있습니다.

1. 월렛은 동일한 개인 키 파생 공개 키와 서명 알고리즘을 사용합니다.

2. 월렛은 동일한 소금 계산 프로세스를 가지고 있습니다.

3. 월렛은 동일한 스마트. 계약 클래스는 구현 세부 사항에서 근본적으로 다르지 않습니다;

앞서 이야기한 경우 Argent와 Braavos 모두 ECDSA 서명 알고리즘을 사용하지만 양쪽은 소금 계산 방법이 다르며 동일한 헬퍼 단어를 사용하면 두 지갑에서 일관되지 않은 계정 주소를 생성하게 됩니다.

계정 추상화에 대해 다시 살펴보겠습니다. 스타크넷과 zkSync 시대는 인증(디지털 서명 확인), 가스비 지불 및 기타 핵심 로직과 같은 거래 처리와 관련된 일련의 프로세스를 "체인 플로어" 외부에서 구현하도록 이동시켰습니다. 사용자는 자신의 계정에서 위 로직의 구현 세부 사항을 사용자 지정할 수 있습니다.

예를 들어, 스타크넷 스마트 콘트랙트 계정에 전용 디지털 서명 확인 기능을 배포하고, 스타크넷 노드가 사용자로부터 트랜잭션을 수신하면 온체인 계정에서 사용자 정의한 일련의 트랜잭션 처리 로직을 호출할 수 있습니다. 이는 분명히 훨씬 더 유연합니다.

그리고 이더리움 설계에서는 인증(디지털 서명)과 같은 로직이 노드 클라이언트 코드에 기록되기 때문에 기본적으로 계정 기능의 커스터마이징을 지원하지 않습니다.

(Starknet) 설계자가 지정한 네이티브 AA 솔루션의 개략도, 거래 검증 및 가스비 적격성 검증이 온체인 계약에 의해 처리되도록 전환되고 체인의 기본 VM이 이러한 기능을 사용자 정의 또는 지정할 수 있음)

지크싱크에라와 스타크넷의 관계자에 따르면 이러한 계정 기능의 모듈화는 다음 아이디어를 기반으로 한다. 그러나 차이점은 zkSync와 스타크넷은 처음부터 계정 유형을 병합하고 거래 유형을 통합했으며 통합 포털을 사용하여 모든 거래를 수신하고 처리하는 반면, 이더는 역사적 부담과 하드 포크와 같은 무차별 반복 솔루션을 최대한 피하려는 재단의 열망으로 인해 EIP-4337 솔루션은 "커브볼" 솔루션이지만, 이로 인해 EOA 계정과 4337 솔루션은 각각 별도의 거래 프로세스를 가지고 있어 어색하고 다루기 힘들며 네이티브 AA만큼 유연하지 못하다는 문제가 있습니다.

(이미지 출처: ArgentWallet)

그러나 스타크넷의 기본 계정 추상화는 아직 완전한 성숙도에 도달하지 못했으며, 실제 진행 상황 측면에서 스타크넷의 AA 계정은 서명 확인 알고리즘의 사용자 정의를 구현하지만 수수료 지불의 사용자 정의에 대해서는 현재 스타크넷은 가스비 지불을 위해 이더리움과 스트로크만 지원하고 있으며, 제3자가 고객을 대신하여 가스비를 지불하는 것은 지원하지 않기 때문에 스타크넷의 네이티브 AA의 진행 상황은 "이론적 솔루션은 기본적으로 성숙하고 실제 솔루션은 여전히 발전 중"이라고 할 수 있습니다.

스타크넷에는 스마트 컨트랙트 계정만 존재하기 때문에 거래의 전체 흐름은 계정 스마트 컨트랙트의 영향을 고려합니다. 먼저, 트랜잭션이 스타크넷 노드의 메모리 풀(Mempool)에 수신되어 검증을 받게 되며, 검증 단계는 다음과 같습니다.

1. 거래의 디지털 서명이 올바른지 여부를 확인하며, 이때 거래 개시자의 계정인 사용자 지정 서명 검증 함수;

2. 거래 개시자의 계정 잔액이 가스비를 지불할 수 있는지 여부;

계정의 스마트 컨트랙트에서 사용자 지정 서명 검증 기능을 사용한다는 것은 공격 시나리오가 존재한다는 것을 의미한다는 점에 유의하세요. <메모리 풀은 새로 들어오는 트랜잭션의 서명을 확인할 때 가스비를 부과하지 않기 때문입니다(가스비를 직접 부과할 경우 더 심각한 공격 시나리오가 발생할 수 있습니다). 악의적인 사용자가 먼저 계정 컨트랙트에서 매우 복잡한 서명 확인 기능을 사용자 정의한 다음, 많은 수의 트랜잭션을 시작하여 이러한 트랜잭션이 확인되면 모두 사용자 정의된 복잡한 서명 확인 기능을 호출하여 노드의 연산 자원을 직접 소진하도록 할 수 있습니다.

이를 방지하기 위해 스탁넷은 트랜잭션에 다음과 같은 제한을 둡니다:

1. 단위 시간당 단일 사용자가 시작할 수 있는 트랜잭션 수에 상한선이 있습니다.

   .

2. 스타크넷 계정 컨트랙트에 커스터마이징된 서명 검증 기능에는 복잡도 제한이 있으며 지나치게 복잡한 서명 검증 기능은 실행되지 않으며, 스타크넷은 서명 검증 기능에 소비되는 가스 양에 대한 상한선을 제한하므로 서명 검증 기능에 소비되는 가스 양이 너무 많으면 거래가 완전히 거부됩니다. 또한 계정 컨트랙트 내에서 서명 확인 기능이 다른 컨트랙트를 호출하는 것도 허용하지 않습니다.

스타크넷 트랜잭션의 흐름도는 다음과 같습니다:

한 가지 주목할 만한 점은 거래 검증 프로세스를 더욱 가속화하기 위해 스타크넷 노드 클라이언트는 브라보스와 아젠트 지갑의 서명 검증 알고리즘을 직접 구현하고, 노드는 거래가 이 두 가지 주류 스타크넷 지갑에서 생성된 것을 발견하면 클라이언트와 함께 제공되는 브라보스/아젠트 서명 알고리즘을 호출합니다. 이 캐시 같은 아이디어를 통해 스타크넷은 트랜잭션 검증 시간을 단축할 수 있습니다.

거래 데이터가 시퀀서(메모리 풀 검증보다 훨씬 더 심층적인 검증 단계)에 의해 검증되면, 시퀀서는 처리를 위해 메모리 풀에서 트랜잭션을 패키징하여 ZK 증명 생성기로 전달합니다. 이 세션에 들어온 트랜잭션은 실패하더라도 가스가 부과됩니다.

그러나 독자가 스타크넷의 역사를 알고 있다면, 초기 스타크넷은 실패한 트랜잭션을 실행하는 데 수수료를 부과하지 않았으며, 가장 일반적인 거래 실패 사례는 사용자가 1 이더만 가지고 있는데 10 이더를 외부로 송금하는 경우임을 알 수 있을 것입니다. 이런 종류의 트랜잭션에는 분명히 논리 오류가 있으며 궁극적으로 실패할 수밖에 없지만, 구체적으로 실행되기 전까지는 결과가 어떻게 될지 아무도 모릅니다.

그러나 스타크넷은 과거에 이러한 실패한 거래에 대해 수수료를 부과하지 않았습니다. 이러한 비용 없는 오류 거래는 스타크넷 노드의 컴퓨팅 리소스를 낭비하고 디도스 공격 시나리오를 초래할 수 있습니다. 오류 거래에 대한 수수료 부과 방식은 표면적으로는 잘 구현된 것처럼 보이지만 실제로는 상당히 복잡합니다. 스탁넷은 실패한 거래에 대한 가스 과금 문제를 해결하기 위해 새로운 버전의 카이로1 언어를 도입했습니다.

우리는 모두 ZK 증명이 유효성 증명이며, 실패한 트랜잭션의 실행은 체인에 남길 수 없는 유효하지 않은 출력을 초래한다는 것을 알고 있습니다. 특정 명령어 실행이 유효하지 않고 출력 결과를 생성할 수 없음을 증명하기 위해 유효성 증명을 사용하려는 시도는 다소 이상하게 들리며 현실적으로 실현 가능하지 않습니다. 그렇기 때문에 과거 스타크넷은 증명을 생성할 때 출력 결과를 생성할 수 없는 실패한 트랜잭션은 간단히 제거했습니다.

이후 스타크넷 팀은 더 스마트한 솔루션을 채택하여 "모든 트랜잭션 명령이 출력과 온체인에 생성될 수 있도록 하는" 새로운 컨트랙트 언어인 카이로1을 구축했습니다. 언뜻 보기에 모든 트랜잭션이 출력을 생성한다는 것은 논리적 오류가 없다는 것을 의미하며, 대부분의 경우 트랜잭션이 실패하는 이유는 명령 실행을 중단시키는 버그를 만나기 때문입니다.

트랜잭션이 중단되지 않고 성공적으로 출력을 생성하도록 만드는 것은 어렵지만, 실제로 트랜잭션이 중단되는 논리 오류가 발생하더라도 출력을 생성하도록 만드는 매우 간단한 대안이 있는데, 그 대신 False 값을 반환하여 이 트랜잭션의 실행이 제대로 되지 않았음을 모든 사람에게 알릴 수 있습니다.

그러나 False 값을 반환하면 출력이 반환되므로, 명령에 논리 오류가 발생했는지 또는 일시적으로 중단되었는지 여부에 관계없이 Cairo1이 출력을 생성하고 온체인할 수 있으며, 이는 올바른 오류 메시지이거나 False 오류 메시지일 수 있다는 것을 의미합니다.

예를 들어 다음과 같은 스니펫이 있다고 가정해 보겠습니다.

p>

여기 _balances::read(from) - 금액이 아래쪽으로 넘쳐나고 있을 수 있습니다. 금액이 하향 오버플로로 인해 오류를 보고하면 해당 트랜잭션 명령이 중단되고 실행이 중지되어 체인에 트랜잭션 결과가 남지 않지만, 다음과 같은 형태로 재작성하면 트랜잭션 실패 시에도 여전히 체인에 남는 출력을 반환하므로,순전히 인식의 관점에서 보면 모든 트랜잭션이 아무런 문제없이 체인에 트랜잭션 출력을 남기는 것처럼 보이며, 정액 수수료를 부과하는 것이 바람직해 보입니다. 고정 수수료는 특히 합리적으로 보입니다.

스타크넷AA 계약 개요

이 글을 읽는 독자 중 일부는 프로그래밍에 대한 배경 지식을 가지고 있을 수 있다는 점을 고려하여 간략하게 개요를 설명합니다. 배경을 이해하실 수 있도록, 스타크넷의 계정 추상화 컨트랙트 인터페이스에 대한 간략한 데모를 보여드리겠습니다:

위 인터페이스 중 __validate_declare__, 즉 는 사용자가 시작한 선언 트랜잭션의 유효성을 검사하는 데 사용되며, __validate__는 주로 사용자의 서명이 올바른지 확인하는 일반 트랜잭션의 유효성을 검사하는 데 사용되며, __execute__는 트랜잭션의 실행에 사용됩니다. 스타크넷 컨트랙트 계정은 기본적으로 멀티콜, 즉 다중 호출을 지원한다는 것을 알 수 있습니다. 멀티콜은 특정 탈중앙 금융 상호작용을 수행할 때 다음 세 가지 트랜잭션을 패키징하는 것과 같이 매우 흥미로운 기능을 제공합니다.

1. 첫 번째 트랜잭션은 토큰을 탈중앙 금융 컨트랙트에 승인합니다

2. 두 번째 트랜잭션은 DeFi 컨트랙트 로직을 트리거합니다

3. 세 번째 트랜잭션은 DeFi 컨트랙트에 대한 승인을 취소합니다

물론 다중 호출은 본질적으로 원자적이므로 특정 재정 거래 실행과 같은 좀 더 복잡한 용도로도 사용할 수 있습니다.

요약

• 스타크넷의 가장 중요한 기술적 특징으로는 ZK 증명 생성을 용이하게 하는 카이로 언어, 네이티브 수준의 AA, 비즈니스 로직과 상태 저장소를 분리하는 스마트 컨트랙트 모델 등이 있습니다.

• 카이로는 스타크넷에서 스마트 컨트랙트를 구현하는 데 사용할 수 있을 뿐만 아니라 보다 전통적인 애플리케이션 개발에도 사용할 수 있는 범용 ZK 언어입니다. 시에라는 컴파일 과정에서 중간 언어로 도입되어 기본 바이트코드를 변경할 필요 없이 카이로를 자주 반복할 수 있으며, 변경 사항만 중간 언어로 전달하면 됩니다. 또한 Cairo의 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조가 통합되어 있습니다.

• 스타크넷 스마트 컨트랙트는 비즈니스 로직과 상태 데이터를 별도로 저장합니다. EVM 체인과 달리 카이로 컨트랙트 배포는 컴파일, 선언, 배포의 세 단계로 구성되며, 여기서 비즈니스 로직은 컨트랙트 클래스에서 선언되고 상태 데이터가 포함된 컨트랙트 인스턴스는 상태 데이터에 연결될 수 있습니다. 상태 데이터를 포함하는 컨트랙트 인스턴스는 클래스와 연결되어 후자에 포함된 코드를 호출할 수 있습니다.

• 위와 같은 스탁넷의 스마트 컨트랙트 모델은 코드 재사용, 컨트랙트 상태 재사용, 스토리지 계층화, 스팸 컨트랙트 탐지를 용이하게 하며 스토리지 임대 및 트랜잭션 병렬화를 실현하는 데도 용이합니다. 후자의 두 가지 기능은 아직 제공되지 않지만 카이로의 스마트 컨트랙트 아키텍처는 이를 위한 '필요 조건'을 만들어냅니다.

• 스타크넷은 체인에 스마트 콘트랙트 계정만 있고, EOA 계정은 없으며, 처음부터 네이티브 수준의 AA 계정 추상화를 지원했습니다. 스탁넷의 AA 체계는 ERC-4337 아이디어를 어느 정도 흡수하여 사용자가 고도로 맞춤화된 거래 처리 체계를 선택할 수 있습니다. 잠재적인 공격 시나리오를 방지하기 위해 스타크넷은 수많은 대응책을 마련하고 AA 생태계를 위한 중요한 탐색을 해왔습니다.