필요한 것 :
- 컴퓨터 과학 배경
- 이더 리움의 기본
- 미적분학의 기초 (제약 최적화)
당신이 얻을 것 :
- 지식이없는 스네이크의 기초
- 머클 나무의 기초
- SNARK 덕분에 Ethereum이 초당 수천 건의 트랜잭션으로 확장 할 수있는 방법
SNARK는 검증자가 W를 밝히지 않고 공유 / 알려진 입력 X로 문제 F에 대한 솔루션 W를 검증 자에게 증명할 수 있도록합니다.
문제에 대한 해결책을 찾으려면 엄청난 양의 계산 능력과 메모리가 필요할 수 있습니다.
따라서 Verifier는 기본적으로 Prover가 제대로 작동하고 솔루션을 찾았 음을 100 % 확신 할 수 있습니다. 솔루션을 확인하거나 솔루션을 전혀 알기 위해 혼자서 작업을 다시 수행하지 않습니다. 마술이야!
이 과정에는 3 단계가 있습니다.
- 설정 — 문제 F (XNUMX 차 산술 프로그램으로 표현해야 함, 아래 참조)는 SNARK를 위해 준비되었습니다. 이 프로세스는 문제의 복잡성 (→ 입력 및 제약 횟수 → 제약 조건 만족 문제의 매트릭스 차원)에 따라 매우 높은 메모리 및 컴퓨팅 집약적입니다. 설정의 출력은 다음 단계에서 사용되므로 설정을 수행하는 플레이어 (Verifier 자체 일 수 있음)는 모든 당사자의 신뢰를 받아야합니다. 설정은 일반적으로 립스나크zkSNARK에 가장 많이 사용되는 C ++ 라이브러리입니다.
- 제공 — 공유 입력 X의 문제 F에 대한 솔루션 W가있는 Prover (아마도 CPU와 메모리를 찾아서 사용했습니다!)는 다음을 사용합니다. 립스나크 그리고의 출력 설정 증명을위한 단계 𝚷. 이 프로세스는 메모리가 높고 컴퓨팅 집약적입니다 (위와 같이 문제의 복잡성에 따라 다름). 출력의 크기 (즉, 증명 𝚷)는 문제의 복잡성과 독립적으로 간결하고 일정합니다. Prover는 출력을 사용하므로 설정 단계를 수행 한 사람을 신뢰해야합니다.
- 확인 — 검증기 — 설정 단계의 출력을 입력으로, 공유 입력 X 및 교정 𝚷 – 교정을 확인합니다. 검증이 성공하면, 검증자는 검증 자에게 W를 밝히지 않고 문제 F에 대한 해결책 W를 찾았 음을 증명할 수있었습니다! 좋은 부분은 증명이 간결하고 항상 같은 길이라는 것입니다. 검증 프로세스는 빠르며 메모리 / 컴퓨팅 집중적이지 않습니다. 이전의 두 단계와 달리 ... 스마트 폰으로 밀리 초 단위로 쉽게 확인할 수 있습니다!
어떻게 이런 일이 일어날 수 있습니까? 글쎄, 멀린 마술이야! 이 배후의 수학을 원한다면 여기에서 시작.
소프트웨어를 XNUMX 차 산술 프로그램으로 변환하려면 어떻게해야합니까?
위에서 언급했듯이 설정 단계의 문제 F는 XNUMX 차 산술 프로그램이어야합니다. 게임의 규칙은 어렵다 :
- 소프트웨어 입력은 숫자 여야합니다. 물건 (배열, 문자열 등)을 숫자로 변환하십시오. 사소한 일입니다.
- "이차적으로 제한된 방정식 시스템"은 다음을 의미합니다.
여기서 x는 입력의 n 차원 벡터이고, m은 제약 조건 수 (즉, 시스템의 방정식 수), C는 n-n-n 계수 매트릭스, q는 n- 차원 계수 벡터입니다. 행렬과 벡터가 마음에 들지 않으면 n = 3 및 m = 2의 경우 (3 개의 입력, 2 개의 제약)가 있습니다.
- 구현은 산술 회로이므로 결과는 다음과 같습니다. 문제 해결됨 (시스템이 해결됩니다. 즉, 모든 다항식이 0과 같습니다) 또는 문제가 해결되지 않았습니다 (다른 모든 경우). 다시 말해서 :“이러한 입력은이 문제에 대한 해결책 중 하나가 아닙니다”.
- C₁, C₂,…, C𝚖, q₁, q₂,…, q𝚖 계수는 시스템의 제약입니다. 이것이 기본적으로 소프트웨어를 정의하는 것입니다. 그것들을 바꾸십시오… 그러면 다른 소프트웨어를 얻게 될 것입니다! SNARK 작동 방식으로 돌아 가기 : C₁, C₂,…, C𝚖, q₁, q₂,…, q𝚖는 설정 단계의 입력입니다. 따라서 설치 단계 (출력 및 검증에 필요)의 출력은 C₁, C₂,…, C𝚖, q₁, q₂,…, q𝚖와 엄격하게 관련되어 있으며 해당 문제에 대해서만 작동합니다. 변경하면 다른 소프트웨어 / 문제를 정의하는 것이므로 설정 단계를 다시 실행해야합니다! x₁, x₂,…, x𝗇는 변수입니다 (즉, 시스템 솔루션을 얻기 위해 추측해야하는 것). 따라서“Dear Prover, 공유 / 공개 입력 X의 문제 F에 대한 비밀 솔루션 W를 찾을 수 있습니까?”라고 말하면“Dear Prover, 시스템을 해결하는 x₁, x₂,…, x𝗇 값을 찾을 수 있습니까? 예를 들어 x₇ = 2393, x₅₂₆ = 5647?” 공유 / 공개 입력으로 제한되는 x₇ 및 x₅₂₆를 제외한 모든 x𝗇으로 원하는 작업을 수행 할 수 있습니다.
힘든 삶이지만 살아남을 수 있습니다 ... 루프가 필요한 경우 동일한 작업을 여러 번 반복하여 반복 할 수 있습니다. 또는 예를 들어 x₁⁴ x₂⁵가 필요한 경우 새 입력 x₃ = x₁⁴ x₂⁵를 정의하고 제약 조건에 x₃를 사용합니다. 변수와 제약 조건을 추가하는 것에 관한 모든 것… 아주 간단한 소프트웨어라도 수억 또는 수십억 개의 입력 및 제약 조건에 쉽게 도달 할 수 있습니다!
더 알고 싶습니까? 읽다 여기에서 지금 확인해 보세요.. 또한이 기본을 확인하십시오 code_to_r1cs.py 이더 리움 / 연구에서.
머클 트리 란?
해시 함수는 임의 크기의 입력을 고정 크기의 출력에 매핑하는 규칙입니다. "Woody Allen"을 "Woen"으로, "Paul McCartney"를 "Paey"로 바꾸는 "쓸데없는 해시 함수"처음 두 글자로 첫 두 문자를 연결하십시오 "를 발명 할 수 있습니다.
머클 트리는 모든 부모가 두 아들의 해시 인 데이터 구조입니다. 맨 위에는 레벨 1의 두 아들의 해시 인 루트가 있습니다. 맨 아래에는 모든 리프가 외부 입력의 해시입니다.
가상의 "Woody Allen"→ "Woen"해시 기능 사용 :
리프가 변경되면 수정 사항이 루트까지 전파됩니다. ANTHONY가 변경되면 ANNY (잎), CENY 및 CECO (루트)도 변경됩니다. 어떤 잎이 바뀌든지, 뿌리도 변합니다.
루트를 다시 계산하기 위해 전체 트리가 필요하지 않습니다. 이 예에서 ANTHONY가 변경되고 JACO와 CECILY를 모두 알고 있으면 JAMES, MARCO, JAES 및 MACO를 완전히 무시하더라도 루트를 쉽게 다시 계산할 수 있습니다. 거대한 나무의 경우 많은 시간이 절약됩니다!
그래서 뭐?
머클 트리는 데이터 무결성 검사에 적합합니다. 일반적으로 유효한 루트가 무엇인지 알고 수신 된 데이터가 해당 루트와 일치하는지 확인합니다. 예를 들어, 지구상에서 사람들의 이름의 전체 데이터 세트를 제공 할 수없는 신뢰할 수있는 당사자 (시간, 대역폭 또는 데이터가 전혀 없음)는 루트 만 제공합니다 (예 : "CECO"). 결과 : 리프 번호와 관련하여 수천 명의 신뢰할 수없는 당사자가 수백만 개의 이름을받습니다. 글쎄, 당신은 올바른 루트를 가지고 있기 때문에 당신은 당신이 신뢰할 수있는 사람, 누가 당신에게 가짜 데이터를 제공하는지 확인할 수 있습니다 ...
머클 나무도 당신 삶의 일부입니다! 3GB Torrent 파일을 다운로드 할 때 파일이 수백만 개의 작은 덩어리로 나뉩니다. 모든 청크의 해시는 리프에 저장됩니다. 유효한 트리의 루트가 어느 것인지 알고 있으므로 누군가가 파일 청크를받을 때마다 올바른지 확인할 수 있습니다. 그렇지 않은 경우 다른 사람에게 동일한 청크를 요청할 수 있습니다.
아직 전체 트리 / 모든 잎을 다운로드하지 않은 경우에도 그렇게 할 수 있습니다. 루트가 CECO이고 JACO를 신뢰하는 경우 ... ANTHONY 청크를 받으면 다운로드하지 않아도 확인할 수 있습니다. 그러나 MARCO와 JAMES 덩어리.
Merkle 나무가 분산 원장 기술에 유용한 이유는 간단합니다. 루트에 대한 합의에 도달하기 위해서만 합의 프로토콜 (느리고 비싸다)을 사용하십시오. 그러면 네트워크의 신뢰할 수없는 노드가 데이터를 효율적이고 직접 공유 할 수 있습니다. 루트와의 무결성 검사 덕분에 안전하고 건전한 수면을 취할 수 있습니다.
하나님 께서 이더 리움에게 보안, 확장 성 및 분산화 중에서 2 개의 초강대국을 선택하라고 요청했을 때… 이더 리움은 확장 성을 희생했습니다. 실제로“초당 트랜잭션 수”에는 강력한 제한이 없습니다.이 제한은 각 블록의 가스량, 즉 각 블록에서 수행 할 수있는 작업량과 관련이 있습니다. 이 한계는 8 백만 가스입니다. 이는 많은 "작은"트랜잭션 (트랜잭션에 첨부 된 데이터, 해당 데이터에 대해 실행할 작업이 없음) 또는 대규모 트랜잭션이 거의 없음을 의미 할 수 있습니다. 거래를 제출하는 것은 Ethereum의 노드와 더 많은 비용을 지불하는 거래를 블록에 포함시키는 Ethereum의 광부에게 달려 있습니다.
블록 채굴 매주 ~ 15 초 이는 분당 32 만 가스를 의미하며, 이더 리움의 Dapps가 주류가 되길 원한다면 충분하지 않습니다.
그건 그렇고 : Ethereum과 Visa의 지루한 비교를 그만 두십시오. 중앙 집중식 시스템은 항상 설계 상 이더 리움보다 빠릅니다. 그들은 다른 일을하고 다른 상황에서 필요합니다. 탈 중앙화와 무 신뢰 환경이 필요하지 않다면 물론 Visa를 선택해야합니다. 한마디로 : 블렌더가 세탁기보다 빠르게 회전한다고해서 블렌더에서 바지를 닦을 수는 없습니다!
퍼즐을 맞추자! SNARK 덕분에 하나의 큰 트랜잭션으로 많은 작은 트랜잭션을 "압축"할 수 있다고 상상해보십시오. 이 큰 거래에서 소비 된 가스가 작은 거래에서 소비 한 가스의 합보다 적 으면 가스를 절약 할 수 있습니다.
그리고 가스 절약은 다음을 의미합니다.
- 전체 거래에 대한 지출이 적은 사용자 → 전체 생태계에 대한 추진
- 블록에 더 많은 물건을 넣을 수 있음 → 이더 리움이 믹서기보다 빠르게 회전합니다!
어떻게 진행합니까?
거래와 스마트 계약을 집계하는 중계자 (또는 더 많은 중계자)가 있습니다.
- 이 게임을 할 의향이있는 사용자는 공개적으로 감사 된 스마트 계약에 Ether (또는 토큰)을 보냅니다. 모든 새로운 플레이어에 대해 머클 트리의 새 잎이 만들어집니다. 리프에는 Ether의 소유자 (공개 키이기도 한 주소), Ether 및 Nonce (계정의 거래 카운터, 리프 추가시 0)에 대한 정보가 포함됩니다.
- A가 Ether을 B로 보내려고 할 때 (모두 스마트 계약에 잎 / 계정이 있어야 함) A는 트랜잭션을 포장합니다. 에계정, 에 계정, 로마 교황 사절 from 계정의 양 양도 될 Ether의 서명 거래의 ( "보낸 사람"계정의 개인 키로 서명 된). 그런 다음 포장 된 트랜잭션을 중계기로 보냅니다.
- 중계기는 주어진 시간 창 (예 : XNUMX 시간)에 수신 된 모든 거래를 집계하고 Merkle 트리를 새로운 잔액으로 업데이트하고 모든 서명과 새로운 Merkle 트리의 루트가 유효하다는 것을 증명하는 SNARK 증명을 만듭니다. 중계기는 최종적으로 새로운 상태와 증명을 스마트 계약에 보냅니다.
- 스마트 컨트랙트는 Proof on-chain을 검증합니다. 유효하면 New state의 Merkle tree root를 계약의 내부 메모리에 저장합니다.
기본적으로 머클 트리 루트는 모든 계정의 전체 상태를 나타냅니다. 그리고 제출 한 새로운 루트로 요약 된 거래가 New state로 이어지는 서명의 유효성을 입증 할 수 없다면이를 변경할 수 없습니다 (= 돈을 훔치십시오).
간단히 말해, 사용자는 코인베이스와 달리 서명없이 코인베이스와 달리 아무것도 할 수없는 중계기를 신뢰할 필요없이 매우 빠르고 무료로 거래 할 수 있습니다.
머클 나무 뿌리로 요약 된 상태가 아닌 양육권이없는 사이드 체인입니다.
SNARK에 대해 위에서 배운 것과 스케일링에 관해 방금 논의한 것을 연결합시다. 여러 가지 방법이 있습니다. 두 가지 레시피를 비교해 보겠습니다 : Vitalik 's 버전 그리고 barryWhiteHat 's 버전.
설정은…
프로젝트를 시작하고 스마트 계약을 생성하는 사람. 감사가 가능할수록 더 좋습니다. 신뢰할 수있는 설정!
현명한 계약은…
2 개의 머클 루트 (바이트 32 값) : 첫 번째 트리에는 계정의 주소 (공개 서명), 두 번째 계정의 잔액 및 논 스가 포함됩니다
제공은…
릴레이
중계기가 스마트 계약으로 보냅니다…
- New state의 2 Merkle roots (주소 트리 및 잔액 + 논스 트리)
- 서명이없는 거래 목록 “각 트랜잭션에는 바이트 당 68 개의 가스가 필요합니다. 따라서 정기적 인 이체의 경우 한계 비용은 68 * 3 (에서) + 68 * 3 (에서) + 68 * 1 (수수료) + 68 * 4 + 4 * 2 (금액) + 68 * 2가 될 것으로 예상 할 수 있습니다 (nonce) 또는 892 가스”
프로빙 프로세스의 알려진 입력은 다음과 같습니다.
- 2 올드 스테이트 머클 뿌리
- 2 개의 새로운 주 머클 뿌리
- 거래 목록
프로빙 프로세스는 다음을 증명합니다.
주어진
- 2 개의 오래된 주 머클 뿌리 (이미 계약서에 저장 됨)
- 2 개의 새로운 상태 머클 루트 (응답 트랜잭션에서 보냄)
- 거래 목록 (응답 거래에 전송)
… 중계기에는 2 개의 오래된 루트가있는 상태에서 해당 트랜잭션이있는 2 개의 새로운 루트가있는 상태로 이동할 수있는 유효한 서명이 있습니다.
확인은 다음과 같이 수행됩니다.
현명한 계약 (원하는대로 견고하고 차가워 짐)
검증 프로세스의 알려진 입력은 다음과 같습니다.
동일한 PROVING의 프로세스는 입력을 명확하게 알고 있습니다 ...!
확장 성 제한
모든 집계 된 거래는 SNARK 검증을 위해 650k 가스를 사용합니다 (고정 비용) 플러스 ~ 900 가스 한계 비용 트랜잭션 당 (데이터를 보내는 데 비용이 듭니다!) 따라서 전체 블록을 사용하여 릴레이는 최대로 집계 할 수 있습니다.
수단 초당 ~ 544tx
barryWhiteHat의 버전
설정은…
프로젝트를 시작한 사람.
현명한 계약은…
1 현재 상태의 머클 루트. 모든 리프는 계정의 해시 상태입니다.
MMCC에 대해 더 살갑게 듣고 싶으시다면, 만들 계좌?
state = AccountState (pubkey, balance, nonce)
state.index = self._tree.append (state.hash ())
제공은…
릴레이
중계기가 스마트 계약으로 보냅니다…
- 증거 𝚷
- 뉴 스테이트 머클 루트
- 증거 𝚷
프로빙 프로세스의 알려진 입력은 다음과 같습니다.
- 올드 스테이트 머클 루트
- 뉴 스테이트 머클 루트
프로빙 프로세스는 다음을 증명합니다.
주어진
- Old Merkle 루트 (계약에 이미 저장되어 있음)
- New Merkle 루트 (Aggr. 트랜잭션에 센티미터)
… 중계기에는 유효한 서명이있는 트랜잭션 목록이 있으며 이전 루트의 상태에서 새 루트의 상태로 이동할 수 있습니다.
확인은 다음과 같이 수행됩니다.
현명한 계약 (원하는대로 견고하고 차가워 짐)
검증 프로세스의 알려진 입력은 다음과 같습니다.
동일한 PROVING의 프로세스는 입력을 명확하게 알고 있습니다 ...!
확장 성 제한
중계기가 거래 데이터를 스마트 계약으로 전송하지 않으므로 (비용이 많이 소요됨) 실제로 한계는 SNARK 증명을 확인하기위한 가스의 양입니다.
Howard Wu 's 언급 일 분산 시스템에서 barnaWhiteHat의 SNARK PROVING 단계 실행에 대한 정보 낙관적 거대한 SNARK에서 16666 건의 거래를 확인할 수 있다고 언급합니다 (1 억 개의 제약 조건).
barryWhiteHat도 생각 500k 가스로 체인 내 증거 증명을 확인할 수 있습니다. 즉, 블록 당 16 개의 SNARK (8 백만 / 500k)를 넣을 수 있습니다. ~ 1.07 SNARKs per second ... 이것은 초당 ~ 17,832 tx를 의미합니다 (16,666 * 1.07).
무한대로
- 빛나는 것은 금 / 1이 아닙니다. 증명 단계에서 필요한 컴퓨팅 능력과 메모리의 양은 문자 그대로 충격적 일 수 있습니다. 특히 barryWhiteHat의 버전에서 복잡성의 일부가 오프 체인으로 이동합니다. 배리 쓰기 "7GB의 램과 20GB의 스왑 공간이있는 노트북에서는 초당 20 개의 트랜잭션을 집계하는 데 어려움이 있습니다.". 만약 목표가 초당 17,832 tx라면 ... LOL. 이는 사소한 병렬 계산 문제를 야기합니다. 그러나 거래 당 평균 $ 비용이 일반적인 no-SNARKs 옵션보다 훨씬 저렴하면 게임은 가치가 있습니다.
- 반짝이는 것은 모두 금 / 2가 아닙니다. 관련 데이터 가용성 문제가 있습니다! 계약에는 트리의 루트 만 저장되므로 전체 버전의 트리 (또는 전체 트랜잭션 기록과 동일)가 항상 사용 가능한지 확인해야합니다. 유효한 서명 된 트랜잭션이 있어도 데이터를 사용할 수없는 경우 릴레이가 Old State → Transactions → New State를 증명할 수 없기 때문에 아무것도 할 수 없습니다.
- 릴레이가 신뢰할 수없고 계약의 이더가 외부의 동일한 이더 값을 갖도록하려면 (유동성 문제)… 사용자는 (특정) 릴레이에 의존하지 않고 스마트 계약에서 원하는 금액을 인출 할 수 있어야합니다. 어떻게? 이것은이 101 게시물의 범위에 포함되지 않지만 동봉 된 링크에서 이에 대해 읽을 수 있습니다.
- 머클 트리를 사용하여 현재 상태 (주소, 잔액 및 논스)를 처리하는 방법에 대해 더 알고 싶습니까? 리프 추가, 리프 업데이트 등? 체크 아웃 이 도서관 (테스트 파일 여기에서 지금 확인해 보세요.)이 기본을 사용하는 모듈. 감사합니다 HarryR!
- 개인 Ethereum-SNARK 환경을 설정하고 싶습니까? C ++ (셋업, 증명, 검증)로 오프 체인을 시작합시다 여기에서 지금 확인해 보세요.. 그런 다음 Zokrates를 사용하여 Ethereum으로 이동할 수 있습니다 (추천 만 체인에서 수행됩니다!)REPOWalk Through California 프로그램, 시작하기위한 설명서).
- Merkle 트리 대신 RSA 누산기를 사용하는 것은 어떻습니까? 구글 “rsa 어큐뮬레이터 ethereum” 시작한다…
즐기십시오!
트위터 marco
- 7
- 계정
- All
- 중
- 유효성
- 기초
- 억원
- 가지 경우
- 이전 단계로 돌아가기
- 확인하는 것이 좋다.
- coinbase
- 컴퓨팅
- 일치
- 계약
- 비용
- Current
- 현재 상태
- DApps
- 데이터
- 데이터 세트
- 분산
- 외형 치수
- 분산 된 원장
- distributed ledger technology
- 환경
- 에테르
- 이더리움
- EU
- EV
- 모조품
- 최종적으로
- 먼저,
- 무료
- 기능
- 경기
- 가스
- GitHub의
- 기부
- 덴탈
- 좋은
- 구글
- 큰
- 안내
- 해시
- 여기에서 지금 확인해 보세요.
- 높은
- history
- 방법
- hr
- HTTPS
- 거대한
- 수백
- ia
- 색인
- 정보
- IP
- IT
- 일
- 키
- 휴대용 퍼스널 컴퓨터
- 넓은
- 리드
- 원장
- 레벨
- LG
- 도서관
- 유동성
- 명부
- 주류
- 지도
- 매질
- 백만
- 광부
- 돈
- 개월
- 가장 인기 많은
- 움직임
- 이름
- 네트워크
- 노드
- 숫자
- 행정부
- 주문
- 기타
- 소유자
- 지불
- 사람들
- 플레이어
- 인기 문서
- 힘
- 사설
- 개인 키
- 프로그램
- 프로젝트
- 증명
- 증명하다
- 공개
- 공개 키
- 요약하다
- RSA
- 규칙
- 달리는
- 가장 안전한 따뜻함
- 절약
- 확장성
- 규모
- 스케일링
- 과학
- 보안
- 세트
- 공유
- 공유
- 짧은
- 단순, 간단, 편리
- 크기
- 잠
- 스마트 한
- 똑똑한 계약
- 스마트 폰
- So
- 소프트웨어
- solidity
- 솔루션
- 풀다
- 스페이스 버튼
- 지출
- 스타트
- 시작
- 주 정부
- 미국
- 성공한
- 체계
- 시스템은
- Technology
- test
- 시간
- 토큰
- 상단
- 급류
- 거래
- 거래 내역
- 믿어
- 업데이트
- 사용자
- 가치
- 확인
- 비자
- W
- 누구
- 말
- 작업
- 일
- 가치
- X