경고
이 상자는 보관되었습니다. 개발이 zksync-crypto 저장소로 이동되었습니다. 대신 사용해 보세요.
zkSync Era는 영지식 증명을 사용하여 보안이나 분산화를 손상시키지 않고 Ethereum을 확장하는 레이어 2 롤업입니다. EVM(Solidity/Vyper)과 호환되므로 Ethereum 프로젝트의 99%는 코드 한 줄도 리팩토링하거나 재감사하지 않고 재배포할 수 있습니다. zkSync Era는 또한 개발자가 C++, Rust 및 기타 널리 사용되는 언어로 스마트 계약을 작성할 수 있게 해주는 LLVM 기반 컴파일러를 사용합니다.
이 라이브러리의 목적은 필드 크기에 대한 추가 가정을 사용하여 매우 구체적인 산술 작업을 수행하는 것입니다. 대략적으로 |F|가 포함된 필드 F 있을 것으로 예상됩니다. ~ 64비트(기계어의 크기)(필드 크기에 대한 가정은 산술화 및 게이트 배치 전략에 중요하지 않지만 특정 필드 크기에 의존하는 특정 기능에 대한 가젯 구현에서 주장됩니다).
시스템에는 논리 기능(가젯), 즉 게이트(트레이스에 자신을 입력할 수 있는 엔터티) 및 평가자(다항식 간의 관계)의 계층 구조가 있습니다. 평가자는 나중에 자동으로 함수를 구성하여 만족도를 확인하고 증명을 계산할 뿐만 아니라 일반 및 재귀 검증자를 합성할 수 있는 특성 형식으로 작성됩니다. 게이트에는 게이트 자체가 트레이스에서 위치를 배치해야 하는 논리를 추적할 수 있도록 하는 추가 도구가 연결되어 있습니다. 우리는 Plonk의 복사 제약 조건에 의존하고 "변수"의 복사 가능한 논리적 개체에 대해 작업하여 증명 가능한 최종 진술을 구성합니다. 이 시스템은 AIR 산술화를 위한 것이 아니며 추적의 여러 행에 걸쳐 제약 조건을 표현할 수 없습니다.
일반적으로 추적에는 몇 가지 종류의 열이 포함됩니다. 주요 분리는 다음 사이에 있습니다.
또한 추적을 사용하면 조회 인수를 추가할 수 있습니다. 조회 인수는 조회 테이블 항목을 저장하기 위해 특수 열을 사용하거나 범용 열을 사용할 수도 있습니다. 테이블은 현재 하나의 다항식 세트로만 인코딩되므로 트레이스의 총 길이는 테이블의 총 항목 수보다 커야 합니다.
모든 "게이트"(Rust 유형)는 고유하므로 게이트는 특수 목적 열이나 일반 목적 열에만 배치할 수 있고 둘 다에 배치할 수는 없습니다. 그러한 기능이 필요하다면 새로운 유형의 래퍼를 만드는 것이 가능합니다.
더 높은 수준의 논리 함수(예: 부울 분해, 범위 검사, 0 검사 등)는 CS의 특정 인스턴스에서 일부 게이트가 허용되는지 여부에 따라 회로가 내부적으로 다른 방식으로 자체적으로 기록되도록 만드는 데 사용됩니다. 서로 다른 게이트 세트가 있는 CS의 인스턴스는 Rust 관점에서 다른 유형으로 간주되며, 우리는 정적 점프로의 분기를 줄이기 위해 일부 인라인/상수 소품/컴파일러 작업에 의존합니다.
|F| 이므로 인수를 반복해야 함) 다음과 같이 확장 필드로 이동하도록 변경됩니다. 분모에 0이 나올 가능성이 매우 "큰" 것을 피하기 위해 증인에게 약속한 후 가능한 한 빨리. 증명 시 계산 비용에 미치는 영향은 매우 미미합니다. 우리는 관계 sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta) 통해 시행되는 조회 인수를 사용합니다. 여기서 특수 열 selector(x_i) 에 대한 조회가 있습니다. selector(x_i) 는 단지 신원일 뿐입니다. 또한 추가 차수 경계 검사를 제거하기 위해 테이블을 더 작은 차수의 다항식으로 인코딩하지 않고 대신 0으로 채웁니다. 여러 테이블이 있는 경우(테이블이 하나만 사용되는 경우에도) 테이블 유형에 별도의 ID 열을 사용하므로 테이블 항목에는 (0,0,...,0) 요소가 포함되지 않습니다. 이렇게 1부터 시작합니다.
이와 같은 조회 인수의 한 가지 좋은 특징은 추가 특성으로 인해 모든 (튜플) 다항식에 대해 인수를 반복하는 대신 동일한 테이블에 대해 여러 witness 다항식을 조회하는 경우(필요함)입니다. 별도의 다중성 열과 나중에 몇 가지 중간 다항식 포함) 다중성을 "추가"하고 인수를 다음과 같은 것으로 변환할 수 있습니다. sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) 조회의 총 비용은 1개의 다중성 열과 2(증인 관련) + 1(테이블 관련) 중간 다항식을 인코딩합니다. lhs와 rhs 관계는 화합의 근원입니다.
이 주장의 정확성은 분명합니다. 건전성을 위해 "빠른 조회를 위한 캐시된 몫" 논문 Lemma 2.4의 원래 인수를 사용합니다. witness_0 과 witness_1 의 다중성을 별도로 커밋하는 것보다 total_multiplicity 를 커밋하는 것으로 충분하다는 것을 보여야 합니다.
방정식 sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X) 보유하고 있습니다. witness_0 과 witness_1 이 테이블 t 에 포함되어 있음을 보여줘야 합니다. f = (witness_0 | witness_1) 값을 연결해 보겠습니다. 위의 방정식은 sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) 를 의미합니다(LHS에서 i 의 간격 길이는 위의 것보다 두 배입니다). Lemma 2.4에 따르면 벡터 f 의 모든 좌표가 t 의 좌표라는 의미에서 f subset t : "subset"을 얻습니다. 특히, witness_0, witness_1 subset f subset t .
이 주장은 여러 witness_i 에도 적용됩니다. 선택한 beta 에 대한 나머지 건전성 인수는 위 작업에서와 같이 직접 따릅니다.
0 얻을 수 있는 2^-40 확률과 비교하면 이러한 절충안이 허용되므로 "이전" 필드 확장으로 이동하세요. SHA256 회로에 대한 게이트 + 테이블의 다소 최적의 구성이라고 생각되는 것을 사용하여 SHA256의 8kB에 대한 벤치마크가 있습니다. 증명자가 다소 빠르더라도 FFT를 적절하게 최적화하지 않았으며 증명이 재귀에 사용될 것으로 예상되는 구성에 여전히 Poseidon(Poseidon2 아님)을 사용합니다. 두 스크립트 sha256_bench_recursive.sh 및 sha256_bench_non_recursive.sh 사용하면 해당 테스트(증명이 재귀에 사용될지 여부)를 실행할 수 있으며, 증명 시간을 보려면 Proving is done, taken ... 줄을 찾아야 합니다. , 그 뒤에 실행되는 검증자는 매우 장황하기 때문입니다. 이 벤치마크는 모든 제약 조건이 4차 이하임에도 불구하고 LDE 계수 8을 사용합니다. 그러나 이는 다른 일부 공개 벤치마크에서 사용되는 매개변수입니다. 20비트에 대한 PoW는 무시할 수 있고(30ms) 아직 대수 해시에 대한 PoW를 지원하지 않기 때문에 이러한 증명에는 PoW를 사용하지 않습니다(그러나 이는 ~2배 더 느리므로 무시할 수도 있음). 보안 수준은 대략 100 비트이지만 쿼리 수를 늘려서 FRI 건전성을 높일 수 있으며, 쿼리 수를 늘려도 증명 시간은 늘어나지 않습니다(FRI 비율 변경과 혼동하지 마세요). 추적 길이는 2^16 이고 60개의 범용 열과 너비가 4인 8개의 조회 인수를 사용합니다.
참고: 벤치마크는 기본 아치로 컴파일하려고 시도하며 AArch64(Apple M1 읽기) 아치만 현재 일반적으로 엔드 투 엔드 테스트됩니다. x86-64 산술 구현의 유효성이 테스트되었지만 전체 증명에서는 엔드투엔드가 아닙니다. 최대 성능 x86-64에는 cpu = native 외에 추가 컴파일러 기능 플래그가 필요합니다(AVX512 세트는 기본 CPU에서도 Rust 컴파일러에 의해 사용되지 않습니다).
Boojum 증명자는 다음 중 하나의 조건에 따라 배포됩니다.
귀하의 선택에 따라.
zkSync Era는 수많은 테스트와 감사를 거쳤습니다. 비록 라이브이지만 아직 알파 상태이며 더 많은 감사와 버그 포상금 프로그램을 거칠 것입니다. 우리는 이에 대한 커뮤니티의 생각과 제안을 듣고 싶습니다! 지금 포크하면 중요한 보안 업데이트, 중요한 기능 및 성능 개선이 누락될 수 있다는 점을 언급하는 것이 중요합니다.
이 소프트웨어에는 제3자의 구성요소가 포함되어 있습니다. 이러한 구성요소 및 해당 라이센스의 전체 목록은 제3자 고지 사항 파일을 참조하십시오.
