[About zk series] #02 Cairo

Published in

Decipher Media ｜디사이퍼 미디어

25 min readFeb 27, 2023

서울대학교 블록체인 학회 디사이퍼(Decipher) ZK-STARK 팀에서 영지식 증명 및 그 활용에 대한 글을 시리즈로 연재합니다. 본 시리즈에서는 논문에 나온 의미를 그대로 전달하려다 보니 글 중간중간 영어가 많이 섞여 나올 수 있습니다.

본 게시글은 ZK-STARK 에 대해 분석한 시리즈 중 2편입니다. 이번 편에선 STARK에서 AIR을 프로그래밍을 통해 생성할 수 있도록 해주는 언어인 Cairo의 역할에 중점을 두어 분석합니다.

Disclaimer : 위 글은 Cairo의 실전적인 문법에 대해 다루지 않습니다. Starkware가 Cairo를 만들게 된 배경, 그리고 백서에서 제안한 Cairo의 구조에 대한 부분을 다룹니다. 더불어 필자는 개발자가 아니므로 표현에 다소 오류가 있을 수 있습니다.

Author

Dean

Reviewed by Yohan Lim

[ZK-STARK] Series

# 01. The Birth of STARK

# 02. Cairo

# 03. Transaction Flow

# 04. Application

# 05. Appendix

1. Intro

앞에서 설명한 바와 같이 Scroll, Starkware, Polygon Maiden, Polygon Hermez, zkSync, Aztec 등 수많은 프로젝트들이 범람하며 서로의 존재감을 뽐내고 있는 경쟁자들 가운데 Starkware의 독자적인 생태계를 만들어 준 것은 바로 Cairo라는 독자적인 언어 생태계의 덕택이 큽니다.

Cairo는 Solidity와 같이 EVM 기반의 레거시 코드가 많은 언어도 아니고, 그렇다고 Web2 개발자풀을 레버리지할 수 있는 Rust, Go 등의 언어를 닮은 WASM 형태의 언어도 아닙니다. 그러나 Cairo는 Defillama의 언어 dashboard를 참고할 때, TVL 기준 4위에 해당하는 언어 생태계를 조성했습니다. 이렇게 Cairo는 Aleo의 Leo, Aztec의 Noir, Filecoin의 Lurk 등 여타 다른 zk 프로그래밍 언어들에 비해 생태계 조성이 잘 되어있는 것은 사실이나, 새로운 언어를 습득해야 한다는 것은 Starkware 생태계 형성에 있어서 큰 허들로 작용하는 것은 확실합니다. 실제로도 Solidity와 Vyper라는 두 EVM기반 언어의 TVL합이 전체의 97%에 달합니다. 그럼에도 불구하고 Starkware가 Cairo를 만든 이유는 무엇일까요? 그리고 그렇게 함으로써 달성하고자 한 것은 무엇일까요? 지금부터 Cairo의 백서를 톺아보며 간단하게 알아보도록 하겠습니다.

2. What is Cairo?

“Cairo — 튜링 완전한 STARK 친화적 CPU 아키텍처”

이는 Cairo의 백서의 제목입니다. 어렵게 느끼실 분들도 있을 것 같은데요, 한 단어씩 뜯어서 살펴보겠습니다.

튜링 완전하다는 것은 어떤 종류의 연산이던 전부 수행할 수 있음을 의미합니다. 여러분이 알고계시는 C/C++, Python, Rust, Go 등 현존하는 대부분의 프로그래밍 언어는 튜링 완전성을 갖추고 있다고 간주됩니다.
STARK 친화적이라는 구절은 바로 Cairo를 만들게된 목적을 드러내는 구절입니다. 즉, 본질적으로 Cairo는 STARK 기반의 증명 생성을 프로그래밍으로 대체할 수 있도록 해주는 언어입니다. STARK는 매우 어려운 수학적 과정을 통해 완성되기 때문에, 여기에서 사용되는 Proof를 생성하는 과정을 프로그래밍으로 구현해내는 일 또한 쉽지 않은 일입니다. 더불어 기존 언어의 연산 처리 방식은 Proof를 생성할 때 비효율성을 내재하고 있습니다. 따라서 Starkware는 효율성을 재고하고 개발자 생태계를 구성하기 위해 직접 이러한 증명을 생성할 수 있는 언어인 Cairo를 구현해야 했습니다. 이에 대해서는 뒤에서 더 자세히 다루겠습니다.
CPU 아키텍처는 왜 등장한 말일까요? 이는 Cairo를 만들게 된 과정을 드러냅니다. Proof의 생성을 효과적으로 만들기 위해 Starkware는 이러한 수학적 증명의 생성을 CPU에서 처리할 수 있는 아키텍처를 먼저 개발한 후, 이 아키텍처에서 수행할 수 있는 instruction set을 만들고 이를 명령할 수 있도록 assembly 언어를 만드는 바텀업 방식으로 언어를 만들었습니다. 즉, Cairo는 기본적으로 컴퓨터의 아키텍처 수준에서 긴밀하게 소통하는 저수준 언어입니다. 그러나 이렇게 컴퓨터가 이해하기 쉬운 언어일수록 사람들이 사용하기에는 어려운 측면이 있습니다. 따라서 Starkware는 프로그래머들이 Cairo를 다루기 더 쉽도록 추상성을 강화하여 새로 Cairo1.0이라는 고수준 언어를 제작하기도 했습니다.

“STARK 친화적” : Proof 생성 과정의 비효율 극복

https://blog.pantherprotocol.io/zk-snarks-vs-zk-starks-differences-in-zero-knowledge-technologies/

사실 계산의 무결성을 증명하는 Proof를 쉽게 생성할 수 있도록 도와주는 방법으로는 크게 두 가지가 있습니다. 첫째는 Compiler를 개발하는 방법으로, ZKPDL, Pinocchio, TinyRAM of SNARKs & STARKs 등의 솔루션들이 이러한 방법으로 개발되고 있습니다. 그러나 이러한 방법은 근본적인 연산의 비효율성을 극복하지는 못합니다. 따라서 Cairo는 둘째 방법을 선택합니다. 그것은 바로 CPU 아키텍처단부터 새로 설계하여, Proof를 생성하기에 편한 Assembly를 만들고, 이를 기반으로 Cairo Instruction Set을 만드는 것입니다. 이런 방식을 선택한다면, 이 Instruction set을 만족하는 어떤 언어로 프로그램을 작성하더라도 최적화된 연산을 할 수 있게 되는 것입니다. SNARK의 경우 vnTinyRAM이 유사한 방식을 선택합니다.

그렇다면 위에서 언급된 “근본적이 연산의 비효율”이란 무엇일까요? 위에서 언급했듯 STARK에서 증명자가 생성해야 하는 Proof는 특정 규칙을 만족하는 다항방정식의 형태입니다. 그리고 이러한 증명을 생성하는 것은 아주 복잡한 과정이므로, 연산 과정의 병목으로 작용하고 매우 높은 하드웨어 성능을 요구로 합니다. 따라서 Proof 생성 과정에서 연산을 가볍게 만드는 것은 상당히 중요한 문제입니다. Cairo는 이러한 연산을 최적화하여 효율화합니다.

물론 이런 설명으로도 감이 잘 잡히지 않습니다. 따라서 간단한 예시를 통해 더 개략적으로 이해해보겠습니다.

먼저 간단해 보이는 statement인 x ≠ y 를 다항방정식으로 표현해보겠습니다. 그럼 다음과 같은 식이 나옵니다. ∃a: (x −y)·a = 1. 여전히 쉬워보이지만, x, y뿐만 아니라 새로운 임의의 실수 a를 추가로 가정해야 합니다. 변수가 하나 추가되었고, 뺄셈 연산 1회와 곱셈 연산 1회가 필요하므로 연산의 비효율도 발생합니다. 위의 예시에서 살펴볼 수 있듯이, statement를 다항방정식으로 표현하기 위해 새로운 변수가 필요하거나, 필요한 연산의 개수가 늘어나야 한다면 이는 비효율이 발생했다고 간주할 수 있습니다.

다른 논리이지만 이러한 식으로도 연산의 비효율이 생길 수 있습니다. “x=y가 될 때까지 연산을 반복하라”는 명령으로 요약할 수 있는 statement인 Loop를 생각해봅시다. 이는 일반적으로 B회 연산 시 x=y인 임의의 지점을 찾아 jump(bounding)하여, 실제로 그 지점까지 B번 연산을 반복하는 식으로 이뤄집니다. 일반적으로 컴퓨터가 100번을 단위로 jump를 한다고 가정한다면, 만약 실제로는 2회차에 Loop가 끝난다고 하더라도 컴퓨터는 100번의 연산을 거칩니다. 분명한 비효율이 발생하는 것이지요.

마찬가지로 Branch에서도 이러한 현상이 발생하는데, 이는 더 깊게 다루지 않겠습니다. 중요한 점은, Cairo는 위에서 언급한 것처럼 CPU 아키텍처단부터 새로 설계하는 방식으로 다항방정식으로 표현할 때 생기는 불필요한 연산과 변수의 수를 줄임으로써 Proof 생성의 비효율을 해소하는 정공법을 선택했다는 것입니다.

제목을 더 어렵게 바꿔보자면?

https://aszepieniec.github.io/stark-anatomy/overview

이렇게 Cairo 백서의 제목을 깊이 이해하면서 우리는 Cairo가 무엇을 하기 위해 설계된 언어인지 알 수 있습니다. 그러나 한 단계 더 깊은 이해를 갖추기 위해서, 쉽게 풀어서 쓴 설명을 잠깐 피해서 이 내용을 다음과 같이 백서의 내용에 나오는 설명과 동일하게 조금 더 어렵게 풀어 써보겠습니다.

“Cairo는 **계산의 무결성(Computational Integrity)**을 증명하는 다항방정식 형태의 Proof인 **AIR(Algebraic Intermediate Representation)**을 쉽고 효율적으로 생성하기 위해 CPU 아키텍처단부터 새로 설계하여 만든 폰-노이만 아키텍처입니다.”

앞의 글에서 계산의 무결성에 대해 다루었고, 다항방정식을 만드는 효율성에 대해서는 위에서 충분히 다루었습니다. 폰-노이만 아키텍처는 CPU, 메모리, 프로그램으로 구성되는 현대 대부분의 컴퓨터가 따르는 아키텍처를 의미합니다. 워딩에서 Cairo가 단순히 하이레벨 언어와는 달리 어떤 규약이기에 앞서 하드웨어적인 아키텍처 설계를 의미한다는 것을 더 잘 이해할 수 있게 해줍니다. 이제 이 문장에서 유일하게 이해하지 못하는 단어인 AIR에 대해서 알아보면 STARK가 어떻게 Cairo를 통해 구현되는지 명확하게 이해할 수 있을 것입니다.

3. What is AIR(Algebraic Intermediate Representation)?

Arithmetic Circuit을 이용하는 대부분의 영지식 증명 솔루션은 연산의 output이 0이 되도록 하는 Input(witness)이 존재함을 증명합니다. 그러나 STARK는 AIR(Algebraic Intermediate Representation, 이하 AIR)를 사용하여 증명을 생성하는데, 이는 다항방정식(Polynomial equation)의 형태의 특정한 제약조건(Constraint)을 만족하는 trace(witness)가 존재함을 증명하면서 달성됩니다.

그렇다면 AIR의 정의는 무엇일까요? “table 형태의 특정한 유한체의 원소에 대해 주기적으로 등장하는 특정 열에 위치하는 원소의 특징을 제한하는 다항방정식의 형태의 constraint들의 List” 입니다. 즉 AIR를 통해 proof를 제시하는 경우, 우리가 컴퓨팅을 통해 생성한 다항방정식들을 만족하는 해가 table 안에 있음을 간접적으로 증명할 수 있으면 되는 것입니다.

사실 AIR가 중요하다는 것은 Cairo라는 이름에서도 알 수 있습니다. 지리적으로 이집트의 수도와 관련이 있어서 Cairo라는 이름이 붙은 것이 아니라, 사실 Cairo에는 AIR가 중앙에 숨어있습니다.

Cairo = CPU + AIR

네, Cairo는 CPU의 앞글자인 C와 앞에서 언급한 AIR(Algebraic Intermediate Representation)를 결합하여 작명되었습니다! 아, 그러면 우리는 Cairo라는 이름을 알아보면서 Cairo가 CPU 아키텍처에서 시작된 언어이며, 동시에 AIR 생성의 최적화를 위해 생겨난 언어라는 것을 알 수 있습니다. 물론, Cairo의 실제 Operation은 AIR에서 몇 가지 조건을 더한 RAP(Randomized AIR with Preprocessing)을 통해서 이뤄집니다. 그러나 Cairo의 작명 당시에 완성된 개념이 아니었기에, 이를 이용해 이름이 붙지 못한 것이지요. RAP을 간단하게 설명하자면, 이는 주어진 상태로 정해지는 것이 아니라 Interaction이라는 상호작용을 통해 변환되며, 첫째 열은 나머지 열과 독립적이라는 특징을 더한 AIR이라고 생각할 수 있습니다.

https://www.youtube.com/watch?v=vVgHL5vpJxY

그렇다면 AIR가 무엇인지 조금 추상적인 수준에서 감을 잡아보도록 하겠습니다. 실제로 사용되는 수학적 개념은 매우 어렵고, 이를 그대로 쉽게 설명하는 것은 불가능에 가까우므로 추상화를 적극 활용하여 설명해보도록 하겠습니다. 다시 한 번 AIR와 영지식 증명의 정의를 살펴보겠습니다.

AIR : table 형태의 특정한 유한체의 원소에 대해 주기적으로 등장하는 특정 열에 위치하는 원소의 특징을 제한하는 Polynomial equation의 형태의 constraint들의 List.
영지식 증명 : Prover가 Verifier에게 Computation + Output과 증명을 전달 -> Verifier가 이를 만족하는 Input이 존재함을 증명

그리고 추상화된 예시를 하나 들어보겠습니다. 열과 행이 각각 16개, 2³개인 16 x 2³ Table을 가정해봅시다. 이후 우리가 프로그래밍한 것을 연산으로 변환하여, Constraint1, 2 라는 다항방정식을 생성합니다. 이때 AIR을 생성한다고 함은, 위 Table의 원소에 대해 주기적으로 등장하는, 이를테면 매 3번째 열의 원소들이 부합하는 조건을 갖춘 constraint1, 매 2번째 행의 원소들이 부합하는 조건을 가진 constraint2를 생성한다는 것을 의미합니다.

constraint1,2라는 두 등식을 만족하는 trace가 존재함을 확인하는 경우, 이 table 안에 가능한 후보는 총 20개에 달합니다. 따라서 verifier는 20개 중 정확히 witness가 무엇인지는 알 수 없으나, Table 안에 해가 존재하는 것을 확인했으므로, 결국 witness를 드러내지 않고도 연산의 무결성을 증명했다고 간주할 수 있습니다.

물론 위의 설명은 엄밀히는 틀린 설명입니다. 그러나 필자의 역량으로는 이정도 비유와 설명이 AIR이 어떻게 STARK에서 영지식 증명을 달성하는지 설명할 수 있는 가장 좋은 방법이었습니다. 더 엄밀한 글을 원하신다면, Cairo의 백서를 직접 읽어보시는 것을 추천합니다.

참고로 위의 예시를 활용하면, 우리가 앞에서 피상적으로 “연산의 효율성”이라고 언급하고 지나갔던 부분을 AIR로 구현하는 경우 어떤 요소로 대변할 수 있는지도 알 수 있습니다. 실제로 AIR의 성능은 2가지 변수로 결정됩니다. 첫째는 table의 크기, 즉 number of trace cell이고, 이는 앞에서 언급한 “변수의 개수”와 유사한 개념으로 생각할 수 있습니다. 또한 둘째는 다항방정식 Constraint의 차수입니다. 이는 앞에서 언급한 “연산의 개수”와 유사한 개념으로 생각할 수 있겠죠. 당연히 둘 모두가 작을수록 AIR은 좋은 성능을 지니게 됩니다. 우리는 이러한 예시를 통해서 조금 더 깊게 Cairo에서 영지식 증명이 작동하는 원리에 대해 이해할 수 있습니다.

4. Cairo

Cairo의 설계

Cairo가 제공하는 가장 큰 가치는 역시 하드웨어단부터 새로 설계를 하여 AIR를 생성하는데 최적화된 연산을 제공한다는 것입니다. 그러나 여전히 이론적인 것을 넘어 실제 구현단에서 어떻게 위에서 언급한 최적화를 달성했는지 잘 이해가 되지 않습니다. 따라서 다소 CS적인 이야기가 나오지만, 실제 아키텍처 상의 예시를 통해 어떤 식으로 AIR의 최적화를 달성하는지 알아봅시다.

가장 먼저 Cairo의 메모리 구조는 다소 특이한데, Nondeterministic Continuous Read-Only Random Access Memory 구조를 지닙니다. 이는 매우 경직된 메모리 구조로 execution 도중에 memory의 수정이 불가합니다. 다만 이러한 제한을 통해서 AIR을 활용의 효율성이 극대화됩니다. Memory의 access에는 5개의 trace cell만이 필요할 정도로 말이죠. 물론, 이러한 메모리 구조를 가지고 있음에도 불구하고 read-write 구조에서 가능했던 대부분의 연산을 수행하는데에 큰 지장이 없도록 설계되어 있습니다.

영지식 증명의 특성을 반영해 public memory의 효율성을 재고한 것도 주목할만 합니다. Zk proof의 특성 상 code + output이 공유되어야 하므로 memory cell은 verifier에게 공유되어야 합니다. Cairo의 경우 이러한 공유를 위해 일반적인 연산이 아니라 boundary를 제한하는 방식을 채택해 verifier가 이러한 공유 과정에 4개의 산술만이 필요하도록 만들었습니다.

Cairo는 또한 증명의 검증을 위해 자주 사용되는 Permutation Range check 등의 연산을 최적화합니다. Cairo 상에서는 3개의 trace cell만으로 [0,2¹⁶) 범위 내에 trace가 존재하는지 확인할 수 있으나, 일반적인 binary approach는 16개의 trace cell이 필요할 정도입니다.

이렇듯 Cairo는 하드웨어부터 시작하여 언어의 설계 전반에서 AIR의 성능을 극대화하기 위한 노력을 전방위적으로 기울인 “효율적인 언어”라고 할 수 있습니다.

What does Cairo offers?

Cairo를 만든 이유와, Cairo의 아키텍처를 통해 영지식 증명이 생성되는 개념적인 내용을 넘어서 실제로 Cairo CPU이렇게 완성된 Cairo CPU가 어떤 기능을 제공하는지를 살펴보겠습니다. Cairo가 실제로 제공하는 기능은 정말 다양하지만, 그 중 몇 가지 주목할만한 부분을 다뤄보겠습니다.

Cairo는 최적화된 Instruction Set을 제공합니다.

https://eprint.iacr.org/2021/1063.pdf, Cairo Instruction의 구조

Cairo CPU가 AIR 환경에서 한 번에 연산할 수 있는 기능의 집합을 Instruction Set이라고 합니다. 이는 AIR을 최적화하기 위해 number of trace cell, 즉 변수의 개수를 줄이는 방향으로 디자인되어 있습니다. Cairo는 Algebraic RISC를 통해 모든 명령어가 15bit flags + 3 integers로 구성된 매우 작고 단순한 명령어 set을 구현했습니다. Cairo는 vnTinyRAM of SNARKs보다 20배 적은 변수로도 증명을 생성할 수 있을 정도로 최적화에 있어서는 타의 추종을 불허합니다.

2. Cairo는 실용적인 기능들을 선별적으로 제공합니다

conditional branch, memory, function call, recursion 등 개발자의 관점에서 실용적인 기능을 충분히 제공합니다. 또한 Nondeterministic한 특징으로 인해 Cairo는 Recursive proof, 병렬 연산 등을 제공합니다.

3. Cairo는 자주 쓰이는 연산에 대한 Built-in을 효과적으로 제공합니다.

cryptographic hash function 등 자주 쓰이고 중요한 기능들에 대해 최적화된 연산을 built-in으로 제공합니다. 이는 3번 내용과 함께 최적화뿐만 아니라, 개발자의 편의성을 위해서도 중요한 요소입니다.

4. Cairo는 하나의 framework로 Product Level에서 사용 가능한 표준을 제시합니다.

dydx, Starknet, ImmutableX 등 다양한 product에서 각자 생성한 오프체인 증명이 Cairo 기반인 경우 모두 Ethereum 위의 같은 스마트컨트랙트에서 검증될 수 있습니다. 따라서 Cairo를 사용한다면 프로덕트 레벨에서 STARK에 대한 어떠한 것도 신경쓸 필요없이 프로덕트에만 집중할 수 있고, 이는 생태계 확장에 매우 중요한 요소로 작용합니다.

이렇게 Cairo의 설계에서 녹아나는 철학과 노력은 다양한 기능적 이점을 제공하며, 이러한 이점들은 실제 영지식 증명을 활용하여 프로덕트를 만드는 개발자들에게 도움을 줄 수 있음을 알 수 있습니다.

5. Why not Solidity?

https://medium.com/yagi-fi/provable-vs-composable-computation-or-why-cairo-will-supersede-solidity-6b00e69bfc9e

우리는 위에서 Cairo가 어떤 이점을 제공하는지 백서의 내용을 통해 알아보았습니다. 그러나 근본적인 의문이 해소되지 않습니다. “Proof의 생성과 검증을 쉽게 만드는 것이, 개발자 생태계나 네트워크 효과를 무시하고서도 달성해야 할 정도로 중요한 가치인가?”라는 의문이 바로 그것입니다. 이는 Cairo 등 zk native 언어들이 zkEVM 솔루션들에게 늘 받는 비판이기도 합니다. 효율성과 편의성은 어느 정도의 trade off가 있는 것이 사실입니다. 그러나, Composable Computation에서 Provable Computation으로 넘어가는 paradigm shift를 볼 수 있다는 것이 바로 Cairo 옹호론자들의 주장입니다. 그 이유는 바로 근본적으로 Naive Replay보다 Proof Verification이 훨씬 효율적이기 때문입니다.

이더리움의 Scaling은 더 많은 트랜잭션을 저렴하게 처리하는 것이라고 정의되어 왔습니다. Zk proof를 통해 Naive Replay보다 쉽게 트랜잭션의 진위여부를 검증할 수 있게 된다면 data의 양이 늘어남에 따라 급수적으로 효율적이게 됩니다. (1편 참고) 게다가 후술할 Recursive proof를 통해 매우 많은 트랜잭션을 한 번에 증명할 수 있게 된다면, 확장성은 더욱 드라마틱하게 개선될 수 밖에 없습니다.

그러나 zkEVM 등의 솔루션을 활용하는 경우 다소 효율성을 희생하더라도 EVM-equivalence 내지 EVM-compatible함을 갖춘 상태로 Proof verification과 recursive proof 등이 가능합니다. 물론 이더리움이 무한에 가까운 트랜잭션을 발생시켜야 한다면 Proof 생성 과정의 효율성은 매우 큰 차이로 비춰지겠지만, 현재는 아무도 블록체인이 그런 무한한 확장성을 가져야 한다고 이야기하지 않으므로 Cairo의 방식은 너무 극단적으로 비춰지는 경향이 있습니다.

물론 uint256과 같은 자료형을 felt라는 특이한 integer로 개선한다거나, Solidity compiler단의 핵심 가치인 gas-fee 최적화를 넘어 proof 생성에 최적화된 로우 레벨 구조를 가져간다거나, memory 구조를 write-once로 바꾼다거나, STARK 상에서 매우 비효율적인 Solidity의 Hash function을 개선한다던가 하는 방식의 접근은 분명 제안하는 가치가 있습니다. 그러나 최근에는 다양한 zkEVM 솔루션들이 등장하며 Starkware도 이러한 흐름 속에서 한 극단만을 고수할 수는 없게 되었습니다.

6. Warp & Cairo1.0

이러한 흐름에서 Starkware는 두 가지 발표를 하게 됩니다.

Warp

첫 번째는 바로 Warp의 발표입니다. 이는 Cairo라는 저수준 접근법을 가지고 있는 Starkware의 입장에서는 당연한 선택지였을 것입니다. Cairo는 instruction set을 만족하는 어떤 언어로도 프로그래밍이 가능하므로, Solidity로 짠 코드를 Cairo로 바꾸어서 EVM이 아닌 Cairo의 zkVM 상에서 연산을 수행하는 Language-level zkEVM을 만들 수 있는 것입니다. 이 시점에서 Starkware는 Starnknet이라는 자체 메인넷을 발표하였기에, Warp를 통해 Solidity 개발자들과 dApp들을 유치하고 싶은 고민이 생겼을 것이라고 생각이 듭니다.

https://vitalik.ca/general/2022/08/04/zkevm.html

그러나 EVM 호환성의 측면에서 이는 엄밀히 말해서 Solidity의 모든 기능을 수행할 수 있는 방법은 아니며, EVM compatible 내지 equivalence의 정의에 잘 부합하지 않습니다. 많이들 보아서 잘 아실 비탈릭 부테린의 zkEVM분류 기준에 따르면, 이는 4단계에 속하는 수준으로, 상호운용성을 충분히 보장한다고 보기는 어렵습니다.

Cairo1.0

두 번째는 바로 Cairo1.0이라는 Rust를 닮은 고수준 언어입니다. 물론 Cairo는 이미 많은 Layer-2 솔루션을 빌딩하는데 사용되었으며 수많은 거래를 성공적으로 처리하고 이더리움에 안전하게 오프체인 연산 결과를 settle하며 그 성능을 증명하였습니다.

Cairo의 ERC20 코드. if구문과 uint256 library 등 여러 지원이 추가되었음.

실제로 Cairo는 초반보다 많은 개선사항이 있었습니다. 따라서 초기보다 지금 더욱 사용하기 편하고 좋은 언어가 되었습니다. 그러나 Cairo가 저수준 언어라는 점과, 기존 언어들과 다른 접근법으로 인해 자료형이나 문법적 측면에서 개발자들에게 주는 문제점들은 근본적으로 해결하기는 쉽지 않았습니다. 따라서 더 넓은 개발자풀을 확보하고 접근성을 높이기 위해, 그리고 개발자 친화적인 환경을 조성하여 궁극적으로는 안정성과 편리성을 높이기 위해 Cairo1.0이라는 고수준 언어를 직접 제작하게 됩니다.

Cairo1.0을 런칭한 이후, 두 가지 차이가 발생합니다.

첫째, Sierra라는 중간계층이 Cairo 바이트 코드로의 최종 변환을 위해 새로 생기게 됩니다. Sierra(Safe IntErmdiate RepResentAtion)라는 표현 자체에서 그 효용을 알 수 있는데, cairo로 작성된 코드가 Sierra로 우선 컴파일되고, 컴파일된 코드를 Sierra Assembly에서 바이트코드로 컴파일하는 방식을 채택했습니다. 이렇듯 Sierra를 도입하게 되며 StarkNet에 deploy되는 컨트랙트를 다시 컴파일할 필요가 없어지고, Cairo의 실행의 결과를 모두 검증할 수 있게 됩니다. 이전 버전의 cairo에서는 TRUE, FALSE 또는 Failure의 세 가지 결과가 있습니다. 그러나 Sierra는 카이로 실행이 절대 failure를 출력하지 않도록 보장하고 TRUE 또는 FALSE만을 결과로 도출합니다. Failure 상태의 트랜잭션이 블록에 포함되지 않아 수수료가 발생하지 않았던 바, 잠재적인 Dos(Denial of Service) 공격 위험을 미연에 방지했다고 볼 수 있습니다.

둘째, 개발자 경험이 크게 개선됩니다. Data type 등 기본 문법이 크게 직관적으로 개선될 뿐만 아니라, 안정성도 강화됩니다. IDE 지원과 패키지 관리 등이 개선되었으며, 라이브러리와 opcode 지원 등도 직관성이 개선됩니다.

이러한 방법을 통해, Cairo1.0은 Warp와 함께 Cairo의 생태계를 확장하는 데 많은 도움을 줄 수 있을 것으로 생각됩니다.

Cairo1.0에 대한 더욱 자세한 내용은 본 시리즈 4편에서 다루도록 하겠습니다.

7. Conclusion

지금까지 Cairo를 만든 이유, Cairo의 설계 방식과 구체적인 영지식 증명의 구현에 대해 알아보았습니다. 더불어 Solidity 개발자풀을 Starknet으로 가져오기 위한 프로젝트인 Warp와 새로운 고수준 언어인 Cairo1.0에 대해서도 알아보았습니다. 이후의 글에서는 대부분의 프로젝트들이 zk-SNARK와 zkEVM에 집중하는 현재, zk-STARK에 집중하고 독자적인 생태계를 꾸려가고 있는 Starkware와 Cairo의 실제적인 구현에 대해 더욱 자세히 알아보도록 하겠습니다.