작성자: Shew & Faust, 괴짜 web3

컨설턴트: Starknet 생태계의 핵심 개발자인 CryptoNerdCn, 브라우저 측 Cairo 개발 플랫폼 WASM Cairo의 창립자

요약:

Starknet의 주요 기술 기능에는 ZK 증명 생성을 용이하게 하는 Cairo 언어, 기본 수준 AA, 비즈니스 논리 및 상태 저장에 독립적인 스마트 계약 모델이 포함됩니다.

Cairo는 Starknet에서 스마트 계약을 구현하거나 보다 전통적인 애플리케이션을 개발하는 데 사용할 수 있는 범용 ZK 언어입니다. Sierra는 컴파일 프로세스에서 중간 언어로 도입되어 Cairo가 하위 계층을 변경하지 않고도 자주 반복할 수 있도록 합니다. 변경 사항을 중간 언어로 전송하기만 하면 되며 Cairo의 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조도 포함되어 있습니다.

Starknet 스마트 계약은 비즈니스 로직과 상태 데이터를 별도로 저장합니다. EVM 체인과 달리 Cairo 계약 배포는 "컴파일, 선언 및 배포"의 세 단계로 구성됩니다. 비즈니스 로직은 Contract 클래스에 선언되고 상태를 포함하는 Contract 인스턴스 데이터는 클래스와 결합될 수 있습니다. 연관을 설정하고 후자에 포함된 코드를 호출합니다.

위에서 언급한 Starknet의 스마트 계약 모델은 코드 재사용, 계약 상태 재사용, 저장소 계층화 및 정크 계약 탐지에 도움이 되며 저장소 임대 및 트랜잭션 병렬화 실현에도 도움이 됩니다. 후자의 두 가지는 아직 구현되지 않았지만 카이로 스마트 계약의 구조는 이에 대한 "필요한 조건"을 만들었습니다.

스타크넷 체인에는 스마트 계약 계정만 있고 EOA 계정은 없으며 처음부터 기본 수준의 AA 계정 추상화를 지원합니다. AA 솔루션은 ERC-4337의 아이디어를 어느 정도 흡수하여 사용자가 고도로 맞춤화된 거래 처리 솔루션을 선택할 수 있도록 합니다. 잠재적인 공격 시나리오를 방지하기 위해 Starknet은 많은 대응 조치를 취하고 AA 생태계에 대한 중요한 탐색을 수행했습니다.

텍스트: Starknet의 토큰 발행 이후 STRK는 점차 이더리움 관찰자의 눈에 없어서는 안 될 요소 중 하나가 되었습니다. 항상 "독단적"이고 "사용자 경험에 관심을 기울이지 않는" 것으로 알려진 이 이더리움 레이어 2 스타는 EVM이 활성화된 레이어 2 생태계에서 조용히 자신의 틈새 시장을 개척하며 세상과 초연한 은둔자와 같습니다. 호환성이 널리 퍼져 있습니다.

텍스트: Starknet의 토큰 발행 이후 STRK는 점차 이더리움 관찰자의 눈에 없어서는 안 될 요소 중 하나가 되었습니다. 항상 "독단적"이고 "사용자 경험에 관심을 기울이지 않는" 것으로 알려진 이 이더리움 레이어 2 스타는 EVM이 활성화된 레이어 2 생태계에서 조용히 자신의 틈새 시장을 개척하며 세상과 초연한 은둔자와 같습니다. 호환성이 널리 퍼져 있습니다.

사용자를 너무 무시하고 심지어 디스코드에 '전자 거지' 채널을 공개적으로 개설했기 때문에 스타크넷은 한때 루마오당으로부터 비난을 받았고, '비인간적'이라는 비판을 받는 동시에 그 심오한 기술적 성취는 즉시 '무가치'해졌습니다. UX와 부 창출 효과만이 전부인 것 같습니다. 『금각사』에 나오는 “남들에게 ​​이해받지 못하는 것이 나의 유일한 자랑이 되었다”라는 문구는 그야말로 스타크넷의 자화상이다.

그러나 이러한 사소한 문제를 제쳐두고 순전히 코드 전문가의 "기술적 취향"에 기초한 Starknet과 ZK Rollup의 선구자 중 하나인 StarkEx는 카이로 매니아의 눈에는 거의 보물과도 같습니다. 개발자, Starknet 및 Cairo는 단순히 web3의 모든 것이며 Solidity나 Move는 그들과 비교할 수 없습니다. 오늘날 "기술 전문가"와 "사용자" 사이의 가장 큰 세대 차이는 실제로 사람들이 Starknet에 대한 인식이 부족하기 때문에 발생합니다.

블록체인 기술, 그리고 스타크넷의 가치 발견에 대한 관심과 열망으로 이 글의 저자는 스타크넷의 스마트 컨트랙트 모델과 네이티브 AA에서 시작하여 그 기술적인 솔루션과 메커니즘 설계를 간략하게 정리하여 더 많은 사람들에게 보여주고자 합니다. 스타크넷의 기술적인 특징을 탐구하면서, 우리는 또한 이 "다른 사람이 이해하지 못하는 외로운 레인저"에 대해 사람들이 이해할 수 있기를 바랍니다.

카이로 언어 미니멀 과학 대중화

다음에서는 Starknet의 스마트 계약 모델과 기본 계정 추상화에 중점을 두고 Starknet이 기본 AA를 구현하는 방법을 설명합니다. 이 기사를 읽고 나면 Starknet에서 서로 다른 지갑의 니모닉 문구를 혼합할 수 없는 이유를 누구나 이해할 수 있습니다.

그러나 기본 계정 추상화를 소개하기 전에 먼저 Starknet의 원래 Cairo 언어를 이해하겠습니다. Cairo를 개발하는 과정에서 Cairo0이라는 초기 버전이 있었고 이후에는 최신 버전이 나왔습니다. 최신 버전의 Cairo의 전체 구문은 Rust와 유사하며 실제로는 일반적인 ZK 언어이며 Starknet에서 스마트 계약을 작성하는 것 외에도 일반 애플리케이션 개발에도 사용할 수 있습니다.

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

컴파일 과정의 관점에서 Cairo는 아래 그림과 같이 중간 언어 기반 컴파일 방법을 사용합니다. 사진 속 시에라(Sierra)는 카이로(Cairo) 언어 컴파일 프로세스의 중간 형태(IR)로, 시에라는 스타크넷 노드 장치에서 직접 실행되는 CASM이라는 하위 바이너리 코드 형태로 컴파일될 예정이다.

Sierra를 중간 형태로 도입하면 Cairo 언어가 새로운 기능을 추가하기가 더 쉬워집니다. 많은 경우 기본 CASM 코드를 직접 변경하지 않고 Sierra 중간 언어만 조작하면 됩니다. 이렇게 하면 많은 문제가 줄어들고 Starknet 노드는 클라이언트는 자주 업데이트할 필요가 없습니다. 이러한 방식으로 StarkNet의 기본 논리를 변경하지 않고도 Cairo 언어를 자주 반복할 수 있습니다. 카이로의 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조도 포함되어 있습니다.

Cairo의 다른 혁신에는 Cairo를 다양한 하드웨어 장치에 적응할 수 있는 하위 수준 기계 코드로 컴파일할 계획인 Cairo Native라는 이론적 솔루션이 포함됩니다. Starknet 노드는 스마트 계약을 실행할 때 CairoVM 가상 머신에 의존할 필요가 없습니다. 코드 실행 속도를 크게 향상시킵니다. [아직 이론적인 단계이고 아직 구현되지 않았습니다.]

Starknet 스마트 계약 모델: 코드 로직과 상태 저장의 분리

EVM 호환 체인과 달리 Starknet은 스마트 계약 시스템 설계에 획기적인 혁신을 가져왔으며 이러한 혁신은 향후 출시될 기본 AA 및 병렬 트랜잭션 기능을 위해 크게 준비되었습니다. 여기서 우리는 이더리움과 같은 전통적인 퍼블릭 체인에서 스마트 계약의 배포가 종종 "컴파일 후 배포" 방법을 따른다는 것을 알아야 합니다. ETH 스마트 계약을 예로 들어 보겠습니다.

1. 개발자가 로컬에서 스마트 계약을 작성한 후 편집기를 통해 Solidity 프로그램을 EVM 바이트 코드로 컴파일하여 EVM에서 직접 이해하고 처리할 수 있습니다.

2. 개발자는 스마트 계약을 배포하기 위해 트랜잭션 요청을 시작하고 컴파일된 EVM 바이트코드를 이더리움 체인에 배포합니다.

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

Starknet의 스마트 계약도 "먼저 컴파일한 후 배포"라는 아이디어를 따르지만 스마트 계약은 CairoVM이 지원하는 CASM 바이트코드 형식으로 체인에 배포됩니다. 그러나 스마트 계약의 호출 방법 및 상태 저장 모드 측면에서 계약을 체결하는 경우 Starknet은 EVM 체인과 호환되지 않으며 큰 차이가 있습니다.

정확하게 말하면 이더리움 스마트 컨트랙트 = 비즈니스 로직 + 상태 정보 예를 들어 USDT 컨트랙트는 이체, 승인 등 공통 기능을 구현할 뿐만 아니라 모든 USDT 보유자의 자산 상태를 저장합니다. 코드와 상태는 Together에서 결합됩니다. , 이는 많은 문제를 가져옵니다. 우선 DAPP 계약 업그레이드 및 상태 마이그레이션에 도움이 되지 않으며 트랜잭션의 병렬 처리에도 도움이 되지 않으며 기술적인 부담이 큽니다.

정확하게 말하면 이더리움 스마트 컨트랙트 = 비즈니스 로직 + 상태 정보 예를 들어 USDT 컨트랙트는 이체, 승인 등 공통 기능을 구현할 뿐만 아니라 모든 USDT 보유자의 자산 상태를 저장합니다. 코드와 상태는 Together에서 결합됩니다. , 이는 많은 문제를 가져옵니다. 우선 DAPP 계약 업그레이드 및 상태 마이그레이션에 도움이 되지 않으며 트랜잭션의 병렬 처리에도 도움이 되지 않으며 기술적인 부담이 큽니다.

이와 관련하여 Starknet은 상태 저장 방법을 개선했으며, 스마트 계약 구현 계획에서 DAPP의 비즈니스 로직은 자산 상태와 완전히 분리되어 다른 장소에 저장됩니다. 시스템 효율성을 높이고, 중복되거나 중복된 코드 배포가 있는지 신속하게 식별합니다. 여기서의 원칙은 이렇습니다.

이더리움의 스마트 계약 = 비즈니스 로직 + 상태 데이터 정확히 동일한 비즈니스 로직이지만 상태 데이터가 다른 여러 계약이 있는 경우 이러한 계약의 해시도 달라집니다. 이때 시스템에서는 구별이 어렵습니다. 이러한 계약이 중복되는지, '정크 계약'이 있는지.

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

Starknet의 스마트 계약 시스템에서 계약의 배포 및 사용은 "컴파일, 선언 및 배포"의 세 단계로 구분됩니다. 자산 발행자가 Cairo 계약을 배포하려는 경우 첫 번째 단계는 자체 장치에서 로컬로 작성된 Cairo 코드를 Sierra 및 기본 바이트코드 CASM 형식으로 컴파일하는 것입니다.

그런 다음 계약 배포자는 "선언" 트랜잭션을 발행하고 계약의 CASM 바이트코드와 Sierra 중간 코드를 Contract Class라는 체인에 배포합니다.

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

나중에 자산 계약에 정의된 기능을 사용하려면 DAPP 프런트 엔드를 통해 "배포" 트랜잭션을 시작하고 계약 클래스와 연관된 계약 인스턴스를 배포할 수 있습니다. 이 인스턴스는 자산 상태를 저장합니다. 그 후 사용자는 Contract 클래스의 function 함수를 호출하여 Contract 인스턴스의 상태를 변경할 수 있습니다.

실제로 객체지향 프로그래밍을 이해하는 사람이라면 누구나 스타크넷에서 클래스와 인스턴스가 무엇을 의미하는지 쉽게 이해할 수 있을 것입니다. 개발자가 선언한 Contract Class에는 스마트 컨트랙트의 비즈니스 로직만 포함되어 있어 누구나 호출할 수 있는 함수이지만, 실제 자산 상태가 없기 때문에 "자산 개체"를 직접 구현하지는 않습니다. '영혼'만 있고 '몸'은 없다.

사용자가 특정 계약 인스턴스를 배포하면 자산이 "구체화"됩니다. 토큰을 다른 사람에게 양도하는 등 자산 "엔티티"의 상태를 변경하려는 경우 Contract 클래스에 작성된 함수를 직접 호출할 수 있습니다. 위의 프로세스는 전통적인 객체지향 프로그래밍 언어의 "인스턴스화"와 다소 유사합니다(그러나 완전히 동일하지는 않습니다).

스마트 계약이 클래스와 인스턴스로 분리된 후 비즈니스 로직과 상태 데이터가 분리되어 Starknet에 다음 기능을 제공합니다.

1. 스토리지 계층화 및 "스토리지 임대 시스템" 구현에 도움이 됩니다.

소위 스토리지 계층화는 개발자가 Starknet 체인과 같이 자신의 필요에 따라 사용자 정의된 위치에 데이터를 배치할 수 있음을 의미합니다. StarkNet은 Celestia와 같은 DA 레이어와 호환될 준비가 되어 있으며 DAPP 개발자는 이러한 타사 DA 레이어에 데이터를 저장할 수 있습니다. 예를 들어, 게임은 가장 중요한 자산 데이터를 Starknet 메인넷에 저장하고 다른 데이터는 Celestia와 같은 오프체인 DA 레이어에 저장할 수 있습니다. 보안 요구사항에 따라 DA 레이어를 사용자 정의하는 이 솔루션은 Starknet에서 "Volition"으로 명명되었습니다.

소위 저장고 임대 시스템은 모든 사람이 자신이 점유한 저장 공간에 대해 계속해서 비용을 지불해야 함을 의미합니다. 체인에서 차지하는 공간만큼 이론적으로는 계속해서 임대료를 지불해야 합니다.

이더리움 스마트 계약 모델에서는 계약의 소유권이 불분명하며 ERC-20 계약에 대해 배포자 또는 자산 보유자가 "임대료"를 지불해야 하는지 구별하기 어렵습니다. 오랜 시간 동안 유지되며 계약이 배포될 때만 지불됩니다. 배포자에게 수수료가 부과되는데 이는 합리적인 저장 수수료 모델이 아닙니다.

Starknet, Sui, CKB, Solana의 스마트 계약 모델에서는 스마트 계약의 소유권이 더욱 명확하게 구분되어 스토리지 자금 수집이 더 쉬워집니다. [현재 Starknet은 스토리지 임대 시스템을 직접 출시하지는 않지만 구현될 예정입니다. 미래에]

2. 진정한 코드 재사용을 달성하고 정크 계약 배포를 줄입니다.

체인에 클래스로 저장될 일반 토큰 계약을 선언하면 누구나 이 클래스의 함수를 호출하여 자신의 토큰 인스턴스를 배포할 수 있습니다. 또한 계약은 클래스의 코드를 직접 호출할 수도 있으며 이는 Solidity의 라이브러리 함수 라이브러리와 유사한 효과를 얻습니다.

동시에 Starknet의 스마트 계약 모델은 "정크 계약"을 식별하는 데 도움이 됩니다. 이에 대해서는 앞서 설명했습니다. 코드 재사용 및 정크 계약 감지를 지원한 후 Starknet은 체인의 데이터 양을 크게 줄이고 노드의 저장 부담을 최대한 줄일 수 있습니다.

3.실제 계약 “상태”의 재사용

블록체인에서의 계약 업그레이드는 주로 비즈니스 로직의 변경을 수반하는데, 스타크넷 시나리오에서는 스마트 계약의 비즈니스 로직과 자산 상태가 본질적으로 분리되어 있으며, 계약 인스턴스가 관련 계약 유형 클래스를 변경하면 비즈니스 로직 업그레이드가 완료될 수 있다. 자산 상태를 새로운 곳으로 이전할 필요가 없습니다. 이러한 형태의 계약 업그레이드는 이더리움보다 더 철저하고 기본적입니다.

이더리움 컨트랙트의 비즈니스 로직을 변경하기 위해서는 비즈니스 로직을 에이전시 컨트랙트에 "아웃소싱"해야 하는 경우가 많고, 종속된 에이전시 컨트랙트를 변경하여 주 컨트랙트의 비즈니스 로직을 변경해야 하는 경우가 있는데, 이 방법은 충분히 간단하지 않습니다. 그리고 "원주민이 아니다". .

(이미지 출처:wtf아카데미)

일부 시나리오에서는 기존 이더리움 계약이 완전히 폐기되면 내부 자산 상태를 새 위치로 직접 마이그레이션할 수 없어 매우 번거롭지만 카이로 계약은 상태를 마이그레이션할 필요가 없으며 직접 "재사용"할 수 있습니다. 오래된 것. 상태.

4. 트랜잭션의 병렬 처리에 도움이 됩니다.

일부 시나리오에서는 기존 이더리움 계약이 완전히 폐기되면 내부 자산 상태를 새 위치로 직접 마이그레이션할 수 없어 매우 번거롭지만 카이로 계약은 상태를 마이그레이션할 필요가 없으며 직접 "재사용"할 수 있습니다. 오래된 것. 상태.

4. 트랜잭션의 병렬 처리에 도움이 됩니다.

서로 다른 거래 지시의 병렬성을 최대화하기 위해 필요한 단계는 Bitcoin, CKB 및 Sui에서 볼 수 있듯이 서로 다른 사람들의 자산 상태를 별도의 위치에 저장하는 것입니다. 위 목표의 전제조건은 스마트 계약의 비즈니스 로직을 자산 상태 데이터에서 분리하는 것입니다. Starknet은 아직 트랜잭션 병렬성에 대한 심층적인 기술 구현을 구현하지 않았지만 병렬 트랜잭션은 향후 중요한 목표가 될 것입니다.

Starknet의 기본 AA 및 계정 계약 배포

실제로 소위 계정 추상화와 AA는 이더리움 커뮤니티가 고안한 고유한 개념으로, 많은 새로운 퍼블릭 체인에서는 EOA 계정과 스마트 계약 계정의 구분이 없으며 이더리움 스타일의 계정 시스템은 이더리움 커뮤니티에서 기피되었습니다. 시작. 구덩이. 예를 들어, 이더리움 설정에서 EOA 계정 컨트롤러는 거래를 시작하기 전에 체인에 ETH가 있어야 합니다. 다양한 인증 방법을 직접 선택할 수 있는 방법이 없으며 일부 맞춤형 결제 로직을 추가하는 것은 매우 번거롭습니다. . 어떤 사람들은 이더리움의 계정 디자인이 단순히 반인간적이라고 생각하기도 합니다.

Starknet이나 zkSyncEra와 같은 "네이티브 AA"에 초점을 맞춘 체인을 보면 분명한 차이점을 볼 수 있습니다: 첫째, Starknet과 zkSyncEra는 통합된 계정 유형을 가지고 있습니다. 체인에는 스마트 계약 계정만 있고 그런 것은 없습니다. 처음부터 EOA 계정으로 사용됩니다.(zkSync Era는 기본적으로 사용자가 새로 생성한 계정에 일련의 계약 코드를 배포하여 이더리움 EOA 계정의 특성을 시뮬레이션하여 메타마스크와의 호환성을 촉진합니다.)

스타크넷은 메타마스크 등 이더리움 주변 시설과의 직접적인 호환성을 고려하지 않았으며, 사용자가 스타크넷 지갑을 처음 사용할 때 전용 컨트랙트 계정이 자동으로 배포되는데, 직설적으로 말하면 위에서 언급한 컨트랙트 인스턴스를 배포한다는 뜻이다. 인스턴스는 월렛 프로젝트와 함께 미리 배포되며 컨트랙트 클래스와 연관되어 클래스에 작성된 일부 기능을 직접 호출할 수 있습니다.

다음으로 흥미로운 주제에 대해 이야기하겠습니다: STRK 에어드랍을 받을 때 많은 사람들이 Argent와 Braavos 지갑이 서로 호환되지 않는다는 사실을 발견했습니다. Argent의 니모닉을 Braavos로 가져온 후 해당 계정을 내보낼 수 없습니다. 이는 실제로 Argent와 Braavos 지갑이 있기 때문입니다. Braavos 서로 다른 계정 생성 계산 방법이 사용되므로 동일한 니모닉 문구에 대해 서로 다른 계정 주소가 생성됩니다.

구체적으로 Starknet에서 새로 배포된 계약 주소는 다음 공식을 사용하여 결정론적 알고리즘을 통해 얻을 수 있습니다.

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

위 그림은 스타크넷이 "새 계약 주소"를 생성하기 위해 사용하는 여러 매개변수를 보여줍니다. 배포자_주소는 "계약 배포자"의 주소를 나타냅니다. 이 매개변수는 비어 있을 수 있습니다. 미리 스타크넷 계약 계정이 없더라도, 여전히 새 계약을 배포하세요.

위 그림은 스타크넷이 "새 계약 주소"를 생성하기 위해 사용하는 여러 매개변수를 보여줍니다. 배포자_주소는 "계약 배포자"의 주소를 나타냅니다. 이 매개변수는 비어 있을 수 있습니다. 미리 스타크넷 계약 계정이 없더라도, 여전히 새 계약을 배포하세요.

솔트(salt)는 컨트랙트 주소의 솔트 값을 계산하는 데 사용되는 변수로, 쉽게 말하면 난수(random number)인데, 이 변수는 실제로 컨트랙트 주소의 중복을 방지하기 위해 도입된 변수입니다. class_hash는 앞서 소개한 컨트랙트 인스턴스에 해당하는 클래스의 해시 값입니다. 그리고 constructor_calldata_hash는 계약 초기화 매개변수의 해시를 나타냅니다.

위 공식을 기반으로 사용자는 계약이 체인에 배포되기 전에 생성된 계약 주소를 미리 계산할 수 있습니다. 스타크넷을 사용하면 사용자는 미리 스타크넷 계정이 없어도 계약을 직접 배포할 수 있으며 프로세스는 다음과 같습니다.

1. 사용자는 먼저 배포하려는 계약 인스턴스, 연결하려는 계약 클래스를 결정하고 클래스의 해시를 초기화 매개변수 중 하나로 사용하고 솔트를 계산하여 생성한 계약 주소를 파악합니다.

2. 사용자는 계약을 어디에 배포할지 알고 나면 먼저 계약 배포 수수료로 일정 금액의 ETH를 해당 주소로 이체합니다. 일반적으로 말하면, ETH의 이 부분은 크로스체인 브리지를 통해 L1에서 Starknet 네트워크로 교차되어야 합니다.

3. 사용자는 계약 배포를 위한 트랜잭션 요청을 시작합니다.

실제로 스타크넷의 모든 계정은 위와 같은 과정을 거쳐 배치되지만, 대부분의 지갑은 세부사항을 가려 사용자들이 그 과정을 전혀 인지할 수 없으며, 이는 마치 ETH를 전송한 후 컨트랙트 계정이 배치되는 것과 같습니다.

위의 솔루션은 서로 다른 지갑이 계정 주소를 생성할 때 생성된 결과가 일관되지 않기 때문에 호환성 문제가 발생합니다.다음 조건을 충족하는 지갑만 혼합될 수 있습니다.

앞서 언급한 사례의 경우 Argent와 Braavos 모두 ECDSA 서명 알고리즘을 사용했지만 양측의 솔트 계산 방식이 달랐고, 두 지갑에서 동일한 니모닉 문구로 생성된 계정 주소가 일치하지 않게 되었습니다.

계정 추상화 주제로 돌아가 보겠습니다. Starknet과 zkSync Era는 신원 확인(디지털 서명 확인), 가스 요금 지불 및 기타 핵심 로직과 같은 거래 처리 프로세스와 관련된 일련의 프로세스를 "체인의 최하위 계층" 외부에서 구현하도록 이동합니다. 사용자는 자신의 계정에서 위 로직의 구현 세부 사항을 맞춤 설정할 수 있습니다.

예를 들어, Starknet 스마트 계약 계정에 전용 디지털 서명 확인 기능을 배포할 수 있으며, Starknet 노드가 귀하가 시작한 트랜잭션을 수신하면 온체인 계정에 맞춤화된 일련의 트랜잭션 처리 로직을 호출합니다. 이것은 분명히 더 유연합니다.

이더리움 설계에서 신원 확인(디지털 서명)과 같은 로직은 노드 클라이언트 코드에 하드 코딩되어 있으며 기본적으로 계정 기능의 사용자 정의를 지원할 수 없습니다.

(스타크넷 아키텍트가 지정한 기본 AA 솔루션의 개략도. 거래 검증 및 가스 요금 자격 검증은 처리를 위해 온체인 계약으로 전송됩니다. 체인의 기본 가상 머신은 이러한 사용자 정의 또는 지정된 기능을 호출할 수 있습니다.)

zkSyncEra 및 Starknet 관계자에 따르면 이 계정 기능 모듈화 아이디어 세트는 EIP-4337을 기반으로 합니다. 하지만 차이점은 zkSync와 Starknet은 처음부터 계정 유형을 통합하고, 거래 유형을 통합했으며, 모든 거래를 수신하고 처리하기 위해 통일된 입구를 사용했다는 점입니다. 대략적인 반복 계획을 기다리며 "곡선을 통해 나라를 구한다"는 EIP-4337 계획을 지원합니다. 그러나 결과적으로 EOA 계정과 4337 계획은 각각 독립적인 거래 처리 프로세스를 채택하게 되어 어색하고 부풀려 보입니다. 네이티브 AA와 달리 편리합니다.

(이미지 출처: ArgentWallet)

그러나 스타크넷의 기본 계정 추상화는 아직 완전한 성숙도에 도달하지 못했습니다. 실질적인 진행 상황으로 볼 때 스타크넷의 AA 계정은 서명 확인 알고리즘의 사용자 정의를 구현했습니다. 그러나 수수료 지불 사용자 정의를 위해 현재 스타크넷은 실제로 ETH만 지원하고 STRK는 가스 요금을 지불하며 아직 제3자 가스 결제를 지원하지 않습니다. 따라서 네이티브 AA에 대한 스타크넷의 진전은 "이론적 해결책은 기본적으로 성숙되었으며, 실제적인 해결책은 여전히 ​​발전하고 있다"고 할 수 있다.

스타크넷에는 스마트 계약 계정만 있기 때문에 전체 거래 과정에서 계정 스마트 계약의 영향이 고려됩니다. 먼저 Starknet 노드의 메모리 풀(Mempool)에서 트랜잭션을 수신한 후 이를 검증해야 하며, 검증 단계는 다음과 같습니다.

여기서 주목해야 할 점은 계정 스마트 계약에서 맞춤형 서명 확인 기능을 사용한다는 것은 공격 시나리오가 있다는 것을 의미한다는 것입니다. 왜냐하면 메모리 풀은 새로운 거래의 서명을 검증할 때 가스 요금을 부과하지 않기 때문입니다(가스 요금이 직접 부과될 경우 더 심각한 공격 시나리오로 이어질 것입니다). 악의적인 사용자는 먼저 자신의 계정 계약에서 매우 복잡한 서명 확인 기능을 사용자 정의한 후 대량의 거래를 시작할 수 있으며, 이러한 거래가 확인되면 사용자 정의된 복잡한 서명 확인 기능을 호출하여 노드의 전력을 직접적으로 소모할 수 있습니다. 자원.

이러한 상황을 피하기 위해 StarkNet은 거래에 다음과 같은 제한을 적용합니다.

스타크넷 거래 흐름도는 다음과 같습니다.

스타크넷 거래 흐름도는 다음과 같습니다.

거래 검증 프로세스의 속도를 더욱 높이기 위해 Braavos 및 Argent 지갑의 서명 검증 알고리즘이 Starknet 노드 클라이언트에 직접 구현되어 있으며, 노드가 이 두 주류 Starknet 지갑에서 거래가 생성되었음을 발견하면, 클라이언트에 내장된 알고리즘을 호출하게 되는데, Braavos/Argent 서명 알고리즘은 캐싱과 같은 아이디어를 통해 스타크넷은 거래 확인 시간을 단축할 수 있습니다.

트랜잭션 데이터가 시퀀서의 검증을 통과한 후(시퀀서의 검증 단계는 메모리 풀 검증보다 훨씬 깊음) 시퀀서는 메모리 풀의 트랜잭션을 패키지화하여 ZK 인증서 생성기에 제출합니다. 이 링크로 들어가는 거래가 실패하더라도 가스가 부과됩니다.

그러나 독자들이 Starknet의 역사를 이해한다면 초기 Starknet은 실패한 거래에 대해 처리 수수료를 청구하지 않았다는 것을 알게 될 것입니다.가장 일반적인 거래 실패 상황은 사용자가 1ETH의 자금만 가지고 있지만 10ETH를 전송하는 것입니다. transaction에는 분명히 논리가 있습니다. 실수는 결국 실패할 수밖에 없지만, 실행되기 전까지는 결과가 어떻게 될지는 아무도 모릅니다.

그러나 StarkNet은 과거에 실패한 거래에 대해 수수료를 청구하지 않았습니다. 이 비용이 들지 않는 잘못된 거래는 Starknet 노드의 컴퓨팅 리소스를 낭비하고 DDoS 공격 시나리오로 이어집니다. 표면적으로는 잘못된 거래에 대한 수수료를 부과하는 것이 쉬워 보이지만 실제로는 꽤 복잡합니다. Starknet은 실패한 거래에 대한 가스 수집 문제를 해결하기 위해 Cairo1 언어의 새 버전을 출시했습니다.

우리 모두는 ZK Proof가 유효성의 증거이며 실패한 거래의 결과는 유효하지 않으며 체인에 출력 결과를 남길 수 없다는 것을 알고 있습니다. 특정 명령이 유효하지 않고 출력 결과를 생성할 수 없음을 증명하기 위해 유효성 증명을 사용하는 것은 매우 이상하게 들리지만 실제로는 실행 가능하지 않습니다. 따라서 과거 스타크넷은 증명을 생성할 때 출력 결과를 생성할 수 없는 실패한 트랜잭션을 모두 직접 제거했습니다.

Starknet 팀은 나중에 더 스마트한 솔루션을 채택하고 새로운 계약 언어인 Cairo1을 구축하여 "모든 거래 지시가 출력 결과를 생성하고 온체인이 될 수 있도록" 했습니다. 언뜻보기에 모든 트랜잭션은 출력을 생성할 수 있으므로 논리적 오류가 없음을 의미하지만 대부분의 경우 일부 버그가 발생하여 명령 실행이 중단되어 트랜잭션이 실패합니다.

결코 중단되지 않고 성공적으로 출력을 생성하는 트랜잭션을 달성하기는 어렵습니다. 그러나 실제로는 매우 간단한 대안이 있는데, 이는 트랜잭션에서 논리 오류가 발생하여 중단이 발생할 때 출력 결과를 생성하도록 허용하는 것입니다. False 값을 반환하면 트랜잭션이 원활하게 실행되지 않았음을 모든 사람이 알 수 있습니다.

하지만 False 값을 반환하면 출력 결과도 반환된다는 점에 유의해야 합니다.즉, Cairo1에서는 명령에 논리 오류가 발생하거나 일시적인 중단이 발생하더라도 출력 결과가 생성되어 온체인이 가능합니다. 이 출력은 정확할 수도 있고 거짓 오류 메시지일 수도 있습니다.

예를 들어 다음과 같은 코드 세그먼트가 있는 경우

여기서 _balances::read(from) - amount는 언더플로우로 인해 오류를 보고할 수 있으며, 이때 해당 트랜잭션 명령이 중단되어 실행이 중지되고 트랜잭션 결과가 체인에 남지 않습니다. 다음과 같은 형식으로 트랜잭션이 실패하면 출력 결과가 여전히 반환되어 체인에 남아 있습니다.순전히 시각적인 관점에서 보면 모든 트랜잭션이 성공적으로 체인에 트랜잭션 출력을 남길 수 있는 것처럼 보이며 이는 특별합니다. 통합 처리 수수료를 청구합니다. 합리적입니다.

StarknetAA 계약 개요

이 기사의 일부 독자가 프로그래밍 배경을 가지고 있을 수 있다는 점을 고려하여 다음은 Starknet의 계정 추상 계약 인터페이스에 대한 간략한 데모입니다.

위 인터페이스의 __validate_declare__는 사용자가 시작한 선언 트랜잭션을 확인하는 데 사용되는 반면, __validate__는 일반 트랜잭션을 확인하는 데 사용되며 주로 사용자 서명이 올바른지 확인하고 __execute__는 트랜잭션을 실행하는 데 사용됩니다. Starknet 계약 계정은 기본적으로 다중 통화를 지원하는 것을 볼 수 있습니다. 여러 호출을 통해 특정 DeFi 상호 작용을 수행할 때 다음 세 가지 트랜잭션을 패키징하는 등 매우 흥미로운 기능을 수행할 수 있습니다.

물론 여러 호출은 원자성이므로 특정 재정 거래 수행과 같은 좀 더 복잡한 용도가 있습니다.

요약하다

Starknet의 주요 기술 기능에는 ZK 증명 생성을 용이하게 하는 Cairo 언어, 기본 수준 AA, 비즈니스 논리 및 상태 저장에 독립적인 스마트 계약 모델이 포함됩니다.

Cairo는 Starknet에서 스마트 계약을 구현하거나 보다 전통적인 애플리케이션을 개발하는 데 사용할 수 있는 범용 ZK 언어입니다. Sierra는 컴파일 프로세스에서 중간 언어로 도입되어 Cairo가 하위 계층을 변경하지 않고도 자주 반복할 수 있도록 합니다. 변경 사항을 중간 언어로 전송하기만 하면 되며 Cairo의 표준 라이브러리에는 계정 추상화에 필요한 많은 기본 데이터 구조도 포함되어 있습니다.

Starknet 스마트 계약은 비즈니스 로직과 상태 데이터를 별도로 저장합니다. EVM 체인과 달리 Cairo 계약 배포는 "컴파일, 선언 및 배포"의 세 단계로 구성됩니다. 비즈니스 로직은 Contract 클래스에 선언되고 상태를 포함하는 Contract 인스턴스 데이터는 클래스와 결합될 수 있습니다. 연관을 설정하고 후자에 포함된 코드를 호출합니다.

위에서 언급한 Starknet의 스마트 계약 모델은 코드 재사용, 계약 상태 재사용, 저장소 계층화 및 정크 계약 탐지에 도움이 되며 저장소 임대 및 트랜잭션 병렬화 실현에도 도움이 됩니다. 후자의 두 가지는 아직 구현되지 않았지만 카이로 스마트 계약의 구조는 이에 대한 "필요한 조건"을 만들었습니다.

위에서 언급한 Starknet의 스마트 계약 모델은 코드 재사용, 계약 상태 재사용, 저장소 계층화 및 정크 계약 탐지에 도움이 되며 저장소 임대 및 트랜잭션 병렬화 실현에도 도움이 됩니다. 후자의 두 가지는 아직 구현되지 않았지만 카이로 스마트 계약의 구조는 이에 대한 "필요한 조건"을 만들었습니다.

스타크넷 체인에는 스마트 계약 계정만 있고 EOA 계정은 없으며 처음부터 기본 수준의 AA 계정 추상화를 지원합니다. AA 솔루션은 ERC-4337의 아이디어를 어느 정도 흡수하여 사용자가 고도로 맞춤화된 거래 처리 솔루션을 선택할 수 있도록 합니다. 잠재적인 공격 시나리오를 방지하기 위해 Starknet은 많은 대응 조치를 취하고 AA 생태계에 대한 중요한 탐색을 수행했습니다.