Starkware 기술 아키텍처 및 생태학적 애플리케이션 결합

DAOrayaki

特邀专栏作者

2023-03-05 07:00

이 기사는 약 6175자로, 전체를 읽는 데 약 9분이 소요됩니다

StarkNet과 AI+ML이 옳은 이유를 요약하시오. ZKP를 사용하면 AI ML을 오프체인에서 계산할 수 있으며 생성 증명은 다른 사람이 확인할 수 있습니다.

StarkWare

소개

StarkEx와 StarkNet은 모두 StarkWare 팀에서 개발한 프로젝트입니다. 전자는 애플리케이션 체인과 유사한 Iaas와 유사합니다. StarkWare는 대규모 프로젝트가 독점 애플리케이션 롤업을 개발하는 데 도움을 주고 후자는 범용 애플리케이션을 배포할 수 있는 롤업입니다.

StarkEx: 독점 ZKR 엔진

소개

스타크웨어는 지난해와 올해 상반기 스케일링 기술 솔루션 스타크엑스(StarkEx)를 제공함으로써 서비스형 스케일링(Scaling as a Service) 비즈니스 모델을 만들고 애플리케이션별 네트워크를 구축하며 업계 선두 고객에게 서비스를 제공했다. , Sorare, ImmutableX, DeversiFi 등

전체 구조

워크플로우에는 다음 네 개의 링크가 포함됩니다.
패키지 트랜잭션: 오프체인 서버는 클라이언트 요청을 처리하고 StarkEx가 처리할 수 있도록 여러 트랜잭션을 "배치"로 결합합니다.
트랜잭션 확인 및 상태 업데이트: 오프체인 서버는 트랜잭션이 합법적임을 확인하고 압축된 해시 형식으로 시스템 상태를 업데이트합니다.
거래 증명 생성: 위의 프로세스를 완료한 후 SHARP는 거래의 유효성을 확인하기 위해 거래에 대한 STARK 증명을 생성합니다. 그런 다음 거래 무결성을 보장하기 위해 증명 및 업데이트가 온체인 Verifier 스마트 계약으로 전송됩니다.

온체인 검증 증명: STARK 증명이 검증되면 상태 업데이트가 커밋되고 이더리움 메인넷으로 다시 정산됩니다. 모든 트랜잭션은 오프체인에서 처리되고 검증되며 무결성 증명은 온체인에서 검증됩니다.

SHARP는 여러 StarkEx 클라이언트/응용 프로그램에 대한 증명 생성 서비스를 동시에 제공하는 공유 증명자로서 계산 무결성 주장 증명을 생성합니다.

StarkWare Applications

Verifier는 StarkEx에서 트랜잭션의 정확성을 검증하기 위해 Ethereum에 배포된 스마트 계약입니다.

StarkEx 애플리케이션(그림의 Exchange)은 현물 거래와 레버리지 거래를 구분하여 확장 가능하고 자체 수탁 거래를 지원하는 일련의 애플리케이션입니다. 애플리케이션은 스마트 계약과 백엔드의 두 가지 구성 요소로 구성됩니다.

표준 절차
사용자는 트랜잭션을 시작하고 트랜잭션은 스마트 계약과 직접 상호 작용할 수 있습니다.
각 트랜잭션은 트랜잭션 흐름을 형성하는 고유한 ID를 가지며 StarkEx 응용 프로그램은 트랜잭션 흐름을 백엔드로 전송합니다.
백엔드는 SHARP에 상태 전환을 제출하고 SHARP는 상태 전환에 대한 증거를 생성합니다.
SHARP는 검증자 계약에 증명을 제출하고 검증자가 검증을 완료한 후 검증자는 이를 Verifier Fact Registry에 기록하고 백엔드는 StarkEx 스마트 계약에서 상태 전환을 실행합니다.

StarkEx 스마트 계약은 상태 전환의 유효성을 보장하기 위해 상태 전환이 미리 정의된 규칙을 준수하는지 여부를 확인합니다(유효성 검사자 계약을 통해).

참조 링크: 소개 :: StarkEx 문서

높은 수준의 개요

아래 다이어그램에서 볼 수 있듯이 StarkEx 시스템은 파트너 백엔드에서 사용자 트랜잭션을 수락하도록 설계되었습니다. 그런 다음 이러한 거래는 StarkEx 시스템에 의해 일괄 처리되고 처리됩니다. 위의 스마트 계약 및 백엔드 도입과 결합하여 전체 StarkEx 트랜잭션 처리 프로세스 및 책임 분담은 다음과 같이 요약됩니다.
프런트 엔드에서 StarkEx 클라이언트는 온체인 및 오프체인의 두 가지 작업 유형을 지원합니다. 전자는 표준 이더리움 트랜잭션으로 사용자가 직접 StarkEx 계약을 통해 입출금을 하는 반면, 후자는 dydx와 같은 StarkEx 엔진을 통해 수행되는 작업입니다.
StarkEx 클라이언트의 백엔드에서 설정하고 검증한 주문 검증.
비즈니스 로직, StarkEx 계약(하도급 계약)을 사용자 지정하여 고객 비즈니스 로직을 지원합니다.
트랜잭션 흐름, StarkEx로 전송되는 모든 트랜잭션은 nonce와 유사한 tx_ids라는 연속 식별자를 사용하여 검증되고 인덱싱됩니다.
트랜잭션 발신자는 StarkEx 게이트웨이가 트랜잭션이 올바른지 확인하면 트랜잭션 실행을 보장하고(실제로 즉시는 아님) 체인에서 완료를 기다리는 대신 프런트 엔드에서 미리 사용자에게 표시합니다.
오류 처리, 유효하지 않은 트랜잭션이 감지되면 StarkEx 시스템은 고객의 전문 엔드포인트에 오류를 보고하고 고객은 유효하지 않은 트랜잭션을 빈 목록과 같은 실행할 다른 트랜잭션 목록으로 대체합니다.
배치 검토.체인에서 전송되기 전에 클라이언트가 모든 배치를 검토할 수 있습니다.전환이 예상된 상태와 일치하지 않으면 클라이언트는 승인하거나 롤백할 수 없습니다.

Anti-censorship, 고객이 사용자 요청을 검토하면 StarkEx는 사용자가 StarkEx 계약을 통해 직접 작업을 수행할 수 있도록 허용하며 고객은 지정된 시간 내에 사용자에게 이를 제공해야 합니다. 그렇지 않으면 StarkEx 계약이 동결됩니다.

StarkNet: 유니버설 ZKR

소개

다양한 애플리케이션에 맞게 ZK 롤업을 사용자 지정하는 StarkEx와 달리 StarkNet은 범용 ZK 롤업이며 개발자는 StarkNet에서 애플리케이션을 배포할 수 있습니다.

기본 소개

https://ethereum.org/zh/developers/docs/evm/

이더리움에서는 트랜잭션이 제출될 때마다 모든 노드가 트랜잭션을 확인, 확인 및 실행하여 계산의 정확성을 보장하고 계산된 상태 변경을 네트워크에 브로드캐스트해야 합니다.

StarkNet은 체인 외부에서만 계산을 수행하고 ZK 증명을 생성한 다음 체인에서 증명의 정확성을 확인하고 최종적으로 여러 L2 트랜잭션을 이더리움에서 하나의 트랜잭션으로 패키징합니다. 따라서 StarkNet에서 발생하는 거래 비용은 카풀링(Pinduoduo)과 마찬가지로 거래가 많을수록 비용이 낮아지는 것처럼 동일한 패키징 배치의 다른 거래소에서 공유할 수 있습니다.

또한 각 노드가 트랜잭션을 완전히 실행할 수 있도록 하는 이더리움의 방식과 비교하여 트랜잭션에 대한 ZK 증명을 생성하는 StarkNet의 방식은 네트워크 운영 속도를 크게 향상시키고 온체인 통신 트래픽을 줄이며 네트워크 처리량을 증가시킬 수 있습니다.

요컨대, 계산의 정확성을 확인하는 비교는 교사가 학생들이 지식을 습득했는지 여부를 확인해야 한다는 것입니다. 이더리움의 방식은 반 친구들이 교과서 전체를 암송할 수 있는지 확인하는 것이고, 스타크넷의 방식은 학생들이 종이를 보도록 하는 것입니다. 후자는 더 효율적이고 저렴하지만 여전히 안전을 보장합니다.

EVM 호환

StarkNet 네트워크 자체는 EVM과 호환되지 않으며 ZK 친화적인 Cairo VM의 또 다른 집합이 설계되었습니다.

StarkNet은 Hermez 및 Scroll과 같은 Ethereum opcode용 ZK 회로를 만들지 않았지만 ZK 친화적인 어셈블리 언어인 AIR(Algebraic Intermediate Representation) 및 고급 언어인 Cairo를 만들었습니다.

https://vitalik.eth.limo/general/2022/08/04/zkevm.html

StarkNet은 언어 호환 zkEVM인 Vitalik에 의해 정의된 유형 4 레벨에 속합니다(StarkNet은 맞춤형 가상 머신 때문에 zkVM에 엄격히 속함).

StarkNet 자체는 EVM과 호환되지 않지만 StarkNet은 여전히 다른 방식으로 Ethereum과 호환될 수 있습니다.

1. Warp: Solidity를 카이로 언어로 번역하는 번역기

Warp는 잘 알려진 Ethereum 인프라 팀인 Nethermind가 개발한 Solidity-Cairo 번역기입니다. Warp는 Solidity 코드를 Cairo로 번역할 수 있지만 번역된 Cairo 프로그램은 실행 효율성을 최대화하기 위해 Cairo 기능(예: 내장 함수 호출, 메모리 최적화 등)을 수정하고 추가해야 하는 경우가 많습니다.

2. Kakarot: 카이로 언어로 작성된 zkEVM

카카로트는 카이로에서 작성된 스마트 컨트랙트로 현재 스타크넷(goerli testnet)에 배포되어 있으며 바이트코드는 EVM과 동일합니다. 현재 베타 버전입니다. Ethereum 응용 프로그램은 Kakarot에 배포하여 StarkNet으로 이식할 수 있습니다.
카카로트는 (a) 임의의 EVM 바이트코드 실행, (b) EVM 스마트 계약을 있는 그대로 배포, (c) 카카로트가 배포한 EVM 스마트 계약의 기능(보기 및 쓰기 방법) 호출

현재 EVM의 모든 opcode가 지원됩니다.

https://github.com/sayajin-labs/kakarot

작동 원리

요소

https://david-barreto.com/starknets-architecture-review/#more-4602

StarkNet에는 다섯 가지 구성 요소가 있습니다. Prover(인증자), Sequencer(분류기) 및 StarkNet의 전체 노드와 Ethereum에 배포된 검증자(Verifier) 및 핵심 상태 계약(StarkNet Core)입니다.
우리가 StarkNet에서 거래를 시작하면 오프체인 서버인 분류기(sorter)가 이를 수신, 분류, 확인 및 블록으로 패키징합니다. 트랜잭션을 실행한 다음 상태 전환을 StarkNet Core 계약으로 보냅니다.
증명자는 트랜잭션에 대한 증명을 생성하여 이더리움의 검증자 계약으로 보냅니다.

검증자는 검증 결과를 Ethereum의 StarkNet Core 계약으로 보내고 StarkNet Core 계약에서 새로운 Ethereum 트랜잭션 세트를 트리거하여 기록 보관을 위해 체인의 글로벌 상태를 업데이트합니다. 상태 트랜잭션은 L1 트랜잭션 가스를 저장하기 위해 "calldata"(EIP-4844 이후 Blob)로 전송됩니다. 이러한 "메타데이터"는 StarkNet 전체 노드에서 해독할 수 있습니다.

풀 노드는 기본적으로 스토리지 기능을 수행합니다. 전체 노드는 실행된 모든 트랜잭션의 상태 변경, 메타데이터, 증명 및 레코드를 StarkNet에 저장하고 시스템의 현재 전역 상태를 추적합니다. 필요한 경우 전체 노드는 "메타데이터"를 해독하여 StarkNet의 기록을 재구성합니다.

StarkNet 개발 옹호자 @barretodavid의 StarkNet 아키텍처 검토를 참조하십시오. 【 1 】

브라우저 https://testnet.starkscan.co/, L2 동적 블록 생성, 이더리움 1시간 결제

계정 추상화 및 트랜잭션 모델

Ethereum EOA+CA의 이중 계정 설계와 달리 StarkNet은 EIP 4337의 정신을 바탕으로 기본 계정의 추상화와 단 하나의 계정 설계를 실현합니다.

https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781

다음 그림은 트랜잭션 모델을 보여줍니다.

기본 계정 추상화는 계정 프로그래밍 가능성의 문을 엽니다.StarkNet 개발 옹호자 @barretodavid는 StarkNet에서 휴대폰 하드 지갑을 구현하는 아이디어를 언급했습니다.
Ethereum의 EOA는 Secp 256 k 1 타원 곡선에서 서명 체계 ECDSA만 지원합니다.
대부분의 스마트폰은 이더리움의 타원 곡선을 지원하지 않습니다.
따라서 모바일 지갑은 거래에 서명하기 위해 소프트웨어에 의존해야 하며 따라서 모바일 지갑은 핫 지갑입니다.

StarkNet의 기본 계정 추상화는 다중 타원 곡선을 지원하고 서명 검증은 고도로 프로그래밍 가능하므로 StarkNet/Cairo 기반 모바일 지갑을 하드 지갑으로 완전히 전환할 수 있습니다.

https://github.com/spartucus/nistp 256-cairo

카이로는 이미 nistp 256(Smartphone Secure Enlave용)을 구현했습니다.

STARK

간단히 말해서 휴대폰의 암호화 모듈을 직접 호출하여 트랜잭션을 "하드 서명"하는 것입니다.

현재 Halo, PLONK, Groth 16, Groth 09, Marlin, Plonky 2 등과 같은 다양한 증명 시스템(증명 생성 및 확인)이 있으며 모두 SNARK 증명 시스템에 속합니다. 증명 시스템에는 증명을 생성하는 증명자와 증명을 검증하는 검증자가 있습니다. 서로 다른 ZK 프로젝트는 거의 모두 서로 다른 증명 시스템을 사용하며 StarkNet에서 사용하는 STARK는 어떤 의미에서 특별한 SNARK에 속합니다.

STARK는 SNARK보다 더 많은 혁신을 가지고 있습니다. SNARK와 같은 "신뢰할 수 있는 설정"에 의존할 필요가 없습니다. 또한 더 간단한 암호화 가정과 함께 제공되며 타원 곡선, 페어링 및 지수 지식 가정의 필요성을 피하고 순전히 해싱 및 정보 이론에 의존하므로 양자 공격에 대한 내성이 있습니다. 일반적으로 STARK는 SNARK보다 더 안전합니다.

https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/

확장성 측면에서 STARK가 더 확장 가능합니다. 증명 생성 속도는 선형적으로 확장 가능하며 검증 시간과 증명 크기는 대수적으로 확장 가능합니다. 그러나 단점은 생성된 증명 크기가 더 크다는 것입니다. 그러나 증명의 크기가 증가함에 따라 검증 비용은 약간 감소합니다. 즉, 증명의 크기가 클수록 총 비용은 낮아집니다.

정리하면 SNARK에 비해 STARK가 더 안전하고 검증 규모가 커질수록 평균 검증 시간과 증명 크기가 줄어드는 단점이 있지만 초기 증명 크기가 커서 대규모 적용에 더 적합하다는 단점이 있다. .

세부 확장

증명 시간은 선형적으로 확장됩니다. 증명자가 소비하는 시간은 해시 호출 수에 따라 대략 선형적으로 확장됩니다.

https://eprint.iacr.org/2021/582.pdf

80비트의 보안 수준에서 STARK의 12288개 해시 호출마다 증명자의 실행 시간은 1초(12288회/초)이고 98304개 해시 호출마다 10초(9830회/초)가 필요합니다. STARK의 검증 시간과 해시 호출은 기본적으로 선형에 가까운 것으로 알려져 있습니다. 아래 그림과 같이

**확인 및 증명 크기 대수 척도: 확인 시간(및 증명 크기)은 해싱 호출과 함께 대수적으로 확장됩니다. **아래 그림과 같이:

왼쪽 그림에서 알 수 있듯이 해시 호출이 3072에서 49152로 증가하면 검증 시간이 40밀리초에서 60밀리초로 늘어납니다. 그리고 해시 호출이 49152에서 786432로 증가했을 때 확인 시간은 60ms에서 80ms로 증가했을 뿐입니다. 같은 크기의 증거. 따라서 해시 호출이 많을수록 평균 검증 시간이 짧아지고 평균 증명 크기(해시 값/증명 생성을 위해 해시를 호출)가 작아지는 것을 알 수 있습니다.

재귀 증명"지식 체계(특히 STARK)의 모든 일반적이고 간결한 증명/인수를 사용하여 점진적으로 계산을 검증할 수 있습니다. 이것은 계산이 해당 계산의 이전 인스턴스의 정확성에 대한 증거를 생성할 수 있음을 의미하며, 비공식적으로 "재귀 증명 구성"으로 알려진 개념입니다."또는

재귀 STARK".

https://medium.com/starkware/recursive-starks-78 f 8 dd 401025

즉, 재귀 STARK 증명자는 시스템 상태가 a에서 a+1로 이동할 수 있다는 진술에 대한 증명을 생성할 수 있습니다. 증명자는 a의 계산 무결성에 대한 (재귀적) 증명을 확인하고 상태 a의 계산을 충실히 수행했기 때문에 새로운 상태 a+1에 도달합니다. 요컨대, 프로세스가 두 가지 증명 a와 a+1을 하나의 증명으로 결합한다는 것을 이해할 수 있습니다. 아래 그림과 같이:

카이로 VM: 계산 정확성 확인

카이로 VM 개요

때때로 StarkNet OS/Cairo OS의 형태로 나타나기도 합니다.. 계산을 수행하는 EVM과 달리 Cairo VM 자체는 계산을 위한 증명만 생성하고 정확성을 검증합니다.

Cairo VM은 von Neumann 아키텍처를 사용한 CPU VM으로 프로그래밍 언어를 Cairo라고도 하는데 Cairo 언어는 Cairo 어셈블리를 기반으로 하므로 컴파일 효율이 매우 높다. 카이로는 CPU Algebraic Intermediate Representation의 약자입니다. Cairo VM에는 이 "CPU"의 명령 집합을 확인하기 위한 단일 AIR가 포함되어 있습니다.

작동 방식과 관련하여 수신된 트랜잭션을 기반으로 시스템의 L2 상태를 업데이트합니다. (카이로 기반) StarkNet 계약의 실행을 용이하게 합니다. 운영 체제는 Cairo를 기반으로 하며 본질적으로 STARK 증명 시스템을 사용하여 출력을 증명하고 검증하는 프로그램입니다. StarkNet 계약에서 사용할 수 있는 특정 시스템 작업 및 기능은 운영 체제에 대한 호출로 사용할 수 있습니다.

카이로 언어 개요

카이로는 STARK 설계를 기반으로 하는 StarkNet의 스마트 계약 언어이며 카이로 프로그램은 STARK 증명을 생성할 수 있습니다.

카이로 프로그램은 어셈블리 코드의 모음이며 카이로 개발자는 카이로 어셈블리 대신 고급 언어인 카이로로 스마트 계약을 작성할 것입니다. 카이로 프로그램을 작성할 때 카이로 컴파일러는 카이로 코드를 카이로 어셈블리로 컴파일하고 카이로 어셈블러는 어셈블리 코드를 사용하여 카이로 VM에서 실행할 카이로 바이트코드(카이로 CPU에서 실행)를 생성합니다. 또한 실제 시스템에서 opcode 및 기계 코드(및 명령어)로 컴파일해야 합니다.

비결정적 계산

카이로 프로그램의 목표는 특정 계산이 올바른지 확인하는 것이므로 이러한 결정론적 계산에 비해 지름길을 택할 수 있습니다. 이는 계산을 증명하기 위해 검증자가 계산의 일부가 아닌 추가 작업을 수행할 수 있음을 의미합니다.

예를 들어, x = 961의 제곱근 y가 0, 1,…, 100 범위에 있음을 증명하십시오. 간단한 접근 방식은 961에서 시작하여 루트를 계산하고 이 루트가 필요한 범위 내에 있는지 확인하는 복잡한 코드를 작성하는 것입니다.

의사 코드는 다음과 같습니다. y의 값을 추측합니다(이는 비결정적 부분입니다). y 2를 계산하고 그 결과가 x와 같은지 확인합니다. y가 범위 내에 있는지 확인합니다. 그리고 다음 계산 방법을 취하면. Y = SQRT(X) 대신 다음과 같이 계산할 수 있습니다(비결정적 계산). Y*Y=X

보시다시피 두 가지 가능한 솔루션이 있습니다. +Y 및 -Y 중 하나만 나머지 명령을 충족할 수 있습니다.

이는 일부 카이로 프로그램(위와 같은)이 일부 추가 정보 없이는 효율적으로 실행될 수 없음을 의미합니다. 이 정보는 우리가 힌트라고 부르는 것에 의해 제공됩니다. 힌트는 카이로 러너를 위한 특별한 지침으로 값을 쉽게 도출할 수 없는 비결정론적 문제를 해결하는 데 사용됩니다. 이론적으로 힌트는 모든 프로그래밍 언어로 작성할 수 있습니다. 현재 카이로 구현에서 힌트는 Python으로 작성됩니다.

결정적 및 비결정적 가상 머신 정보

an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine.

여기서 Cairo는 실제로 결정적 Cairo VM과 비결정적 Cairo VM을 포함합니다. 전자는 진지한 zkVM, 증명 및 검증이고 후자는 비결정적 컴퓨팅에 사용됩니다.

Cairo 결정론적 VM의 허용 가능한 입력은 비결정론적 VM의 증인을 구성하며 ZKP는 입/출력 증명으로 증인을 사용해야 합니다. (NP 진술에 대한 증인은 진술이 참인지 효율적으로 확인할 수 있는 정보의 일부입니다. 예를 들어 어떤 그래프에 해밀턴 주기가 존재한다고 명시되어 있는 경우 증인은 그러한 주기입니다. 주기가 주어지면 , 유효한 Hamiltonian 고리인지 효율적으로 확인할 수 있지만 그러한 고리를 찾는 것은 어렵습니다)

병렬 상태 기계입니다.

메모리 모델: 읽기 전용 비결정적

읽기 전용 비결정적 메모리는 각 메모리 셀의 값이 증명자에 의해 선택되고 시간이 지남에 따라 변경될 수 없으며(Cairo 프로그램 실행 중) 변경할 수 없음을 의미합니다. 이 명령은 읽기만 가능합니다. 한 번 쓰기 메모리로 생각할 수 있습니다. 값은 셀에 한 번 쓸 수 있지만 나중에 변경할 수는 없습니다.

연속적이며 비어 있으면 어떤 값으로도 채워집니다.

ROM의 장점은 다음과 같습니다.

RAM보다 저렴하고 간단한 회로

영구 저장,

변조 불가, 데이터 수정 및 삭제 불가

내장 기능: 코드 컴파일 감소

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b 71976 ad 0108

개발자는 내장 함수를 직접 호출하여 컴퓨팅 오버헤드를 줄이고 코드 변환 없이 개발 경험을 최적화할 수 있습니다. 내장 함수를 추가해도 CPU 제약 조건에는 영향을 미치지 않습니다. 그림과 같이 CPU와 내장 함수 간에 동일한 메모리가 공유된다는 의미입니다.

Cairo 아키텍처는 특정 내장 함수 집합을 지정하지 않습니다. 내장 함수는 필요에 따라 AIR(Algebraic Intermediate Representation)에서 추가하거나 제거할 수 있습니다.

CPU 아키텍처: 유연함

더 유연하고 소프트웨어 프로그래밍을 통해 AISC의 성능에 무한히 근접할 수 있습니다(그래서 카이로가 CPU를 할 것인가?). Cairo로 다른 가상 머신을 분기합니다.

부트 로드: 해시에서 프로그램 로드

프로그램은 다른 프로그램의 바이트코드를 메모리에 쓰고 프로그램 카운터를 해당 메모리 세그먼트로 지정한 다음 해당 프로그램을 실행할 수 있습니다. 해시에서 부트로딩하는 사용 사례는 부트로더라는 프로그램이 다른 프로그램의 바이트코드를 계산하고 출력한 다음 이전과 같이 실행을 시작하는 경우입니다. 이렇게 하면 검증자는 전체 바이트코드가 아닌 프로그램의 해시만 알면 됩니다. 여기에는 두 가지 장점이 있습니다.
확장성, 검증 시간 및 프로그램 크기는 STARK 섹션에서 언급한 것처럼 대수 관계를 보여줍니다.

프라이버시, 검증자는 계산을 알지 못한 채 프로그램이 올바르게 실행되는지 확인할 수 있습니다.

연속 메모리: 메모리 주소에 대한 연속 액세스

Cairo에는 프로그램이 액세스하는 메모리 주소가 연속적이어야 한다는 기술적 요구 사항이 있습니다. 예를 들어 주소 7과 9에 액세스하면 프로그램이 종료되기 전에 주소 8에도 액세스해야 합니다(액세스 순서는 중요하지 않음). 주소 범위에 작은 간격이 있는 경우 증명자는 자동으로 이러한 주소를 임의의 값으로 채웁니다. 일반적으로 이와 같은 간격을 두는 것은 메모리를 사용하지 않을 때 소모한다는 의미이기 때문에 비효율적입니다. 너무 많은 허점을 도입하면 정직한 증명자가 수행하기에는 증명 생성 비용이 너무 많이 들 수 있습니다. 그러나 이것은 여전히 건전성 보장을 위반하지 않습니다. 어쨌든 거짓 증거를 생성할 수 없습니다.

StarkNet 생태 인벤토리:

https://h 0 m 83 hhc 6 r.feishu.cn/docx/doxcnS 3 GGdXXc 1 PzKh 9 uTgTR 73 c

풀 체인 게임

Matchbox DAO：https://mirror.xyz/matchboxdao.eth

The Future of On-Chain Gaming：

https://volt.capital/blog/the-future-of-on-chain-gaming

Game 2.0 ：

https://www.guiltygyoza.xyz/2022/07/game 2

풀체인 게임—생산 효율성 + 소비자 경험 변환, 기본적으로 사고(다양한 조직 및 팀의 기사), 실습(체인 및 해커톤의 게임 프로젝트), 자금 조달(금융 및 보조금), 그리고 가장 중요한 것은 활기찬 개발자가 있습니다 지역 사회.

토폴로지 팀인 Lootreamls를 적극 추천합니다.

계약 지갑

컨트랙트 지갑이 하드월렛이 되는 것을 깨닫는 방법은 두 가지가 있습니다.
합의 계층은 휴대폰 하드웨어를 지원합니다. StarkNet(프로그래밍 언어 Cairo)과 같은 기본 계정 추상화의 L2에서 Ethereum과 같은 ECDSA(Secp 256 k 1 )만 지원하는 대신 다양한 타원 곡선을 지원하므로 휴대폰의 암호화 칩/모듈이 거래에 직접 서명할 수 있습니다(대부분의 휴대폰은 ECDSA를 지원하지 않음). 따라서 기본 계정이 추상화된 L2에서 계약 지갑은 하드 지갑과 마찬가지로 하드웨어를 통해 직접 트랜잭션에 서명할 수 있습니다.

지갑 레이어는 서명 전사를 수행합니다. Ethereum과 같은 기본이 아닌 계정 추상화 네트워크에서 계약 지갑은 서명하고 기록할 수 있습니다. EIP-4337과 마찬가지로 검증 로직을 커스터마이즈할 수 있으며 사용자는 휴대폰 하드웨어에서 지원하는 알고리즘으로 서명한 후 이더리움에서 지원하는 ECDSA로 변환한다.