담마시크 Web3 펀드 Superscrypt: 저장 증명이 대량의 크로스 체인 새로운 사용 사례를 열어줄 것이다

역사 데이터 검색

블록체인 역사 데이터는 여러 용도로 사용될 수 있습니다. 자산 소유권을 증명하고, 사용자 행동 및 거래 기록을 기록한 후 이를 체인 상의 스마트 계약이나 애플리케이션에 입력할 수 있습니다. 현재까지 이더리움에 기록된 블록 수는 1,800만 개를 초과했습니다. 그러나 스마트 계약은 최신 256개 블록(또는 최근 약 30분 내의 데이터)만 접근할 수 있습니다. 따라서 "역사 데이터"는 마지막 256개 블록 외의 다른 정보를 의미합니다.

현재 역사 데이터에 접근하기 위해 프로토콜은 일반적으로 Infura, Alchemy 또는 기타 인덱서와 같은 아카이브 노드 제공업체에 쿼리를 요청합니다. 이는 이들 및 그들의 데이터에 대한 신뢰와 의존을 의미합니다.

역사 데이터

하지만 저장 증명을 사용하면 상대적으로 낮은 신뢰 수준으로 데이터 검색을 수행할 수 있습니다.

저장 증명은 블록체인에 저장된 역사 데이터를 검증할 수 있는 제로 지식 증명입니다. 더 구체적으로, "저장 증명"은 과거 특정 블록이 특정 상태에 존재했음을 증명하는 데 사용될 수 있습니다. 이는 제3자나 오라클에 대한 신뢰가 필요 없으며, 대신 저장 증명에 신뢰가 내장되어 있습니다.

저장 증명이 특정 데이터가 이전 역사 블록에 존재하는지 검증하는 데 어떻게 도움이 될까요? 이는 두 단계의 검증을 포함합니다:

단계 1: 특정 블록이 실제로 체인 상의 역사 기록에 존재하는지 확인합니다. 예를 들어, 블록이 원본 체인 역사에 유효한 구성 요소인지 확인합니다.
단계 2: 특정 데이터가 블록의 일부인지 확인합니다. 즉, 특정 거래 등의 정보가 해당 블록의 일부인지 확인합니다(이 부분의 검증은 머클 포함 증명을 통해 수행할 수 있습니다).

수신자(예: 목적 체인의 스마트 계약)는 증명을 완료한 후 데이터의 유효성에 대한 신뢰를 가지게 되어 해당 명령 집합을 실행합니다. 이 개념은 추가적인 체인 외 계산을 실행하고, 데이터를 증명하기 위해 또 다른 제로 지식 증명을 생성하는 방식으로 더욱 확장될 수 있습니다.

간단히 말해, 저장 증명은 신뢰 최소화 방식으로 역사 체인 상 데이터를 검색할 수 있게 해줍니다. 이는 매우 중요합니다. 왜냐하면 우리가 제1부에서 개요한 바와 같이, 우리는 향후 몇 년 내에 Web3가 더욱 다중 체인 및 다층 구조로 발전할 것이라고 생각하기 때문입니다. 다양한 Layer1과 롤업 및 애플리케이션 체인의 출현은 사용자의 체인 상 활동이 여러 체인에서 동시에 이루어질 수 있음을 의미합니다. 이는 여러 도메인에서 사용자 자산, 신원 및 거래 기록의 조합 가능성을 유지할 수 있는 신뢰 최소화 상호 운용성 솔루션에 대한 수요를 더욱 강조합니다. 이것이 바로 저장 증명이 해결할 수 있는 문제입니다.

저장 증명 사용 사례

저장 증명은 스마트 계약이 사전 조건으로서 모든 역사 거래 또는 데이터를 확인할 수 있게 해줍니다. 이는 크로스 체인 애플리케이션 설계에 큰 유연성을 제공합니다.

첫째, 저장 증명은 원본 블록체인에서의 모든 역사 데이터를 증명할 수 있습니다. 예를 들어:

계좌 잔액 및 토큰 소유권
사용자 거래 활동
특정 기간 동안 자산 거래의 역사 가격
다양한 체인 상 유동성 풀의 실시간 자산 잔액

둘째, 저장 증명은 목표 체인으로 전송되어 다양한 크로스 체인 사용 사례를 잠금 해제할 수 있습니다:

사용자가 더 낮은 비용의 L2에서 거버넌스 제안에 투표할 수 있도록 함
NFT 소유자가 새로운 체인에서 NFT를 발행하고 커뮤니티 이익을 얻을 수 있도록 허용
사용자의 특정 dApp과의 역사 및 상호작용에 따라 사용자에게 보상(예: 에어드랍)을 제공
사용자의 종합 거래 및 신용 기록에 따라 이자율 대출 제공
휴면 계좌 복구
미래 거래를 위한 역사 TWAP 계산
여러 체인 상의 유동성 풀에 따라 더 정확한 AMM 거래 가격 계산

본질적으로, 저장 증명은 애플리케이션이 여러 체인에서 사용자의 체인 상 활동 및 역사 기록을 조회하고 이식할 수 있게 하여 다른 체인 상의 스마트 계약이나 애플리케이션에 정보를 제공할 수 있게 해줍니다.

저장 증명 - 사용 사례

다음으로, 저장 증명의 작동 메커니즘을 더 자세한 예를 통해 설명하겠습니다.

저장 증명 메커니즘 사용 사례 상세 설명

가정해 보겠습니다. "X"는 이더리움에서 토큰을 사용하는 DeFi 프로토콜입니다. X는 거버넌스 제안을 발표할 것이며, 프로젝트 팀은 사용자 투표를 촉진하기 위해 비용이 더 낮은 체인에서 이를 발표하고자 합니다. 사용자는 특정 시점(즉, 스냅샷, 예: 블록 #17,000,000)에서 이더리움에서 X 토큰을 보유해야 투표할 수 있습니다.

현재는 어떻게 구현되고 있나요?

현재 방법은 아카이브 노드에 쿼리를 요청하여 블록 #17,000,000에서 요구 사항을 충족하는 토큰 보유자의 전체 목록을 가져오는 것입니다. 이후 DAO 관리자는 해당 목록을 목표 체인의 스마트 계약에 저장하여 최종적으로 기준을 충족하는 투표 목록을 결정합니다. 그러나 이 방법에는 몇 가지 한계가 있습니다:

투표자 목록이 매우 방대할 수 있으며, 매번 스냅샷이 변경되므로 매번 투표 제안의 체인 상 저장 및 업데이트 비용이 매우 높습니다.
아카이브 노드 제공업체 및 그들이 제공하는 데이터에 대한 암묵적인 신뢰가 필요합니다.
DAO를 관리하는 구성원이 투표 목록을 조작하지 않도록 해야 합니다.

저장 증명이 어떻게 구현되는가

우리가 제2부에서 설명한 바와 같이, 비싼 계산은 체인 외 제로 지식 증명 생성기로 위임할 수 있습니다.

zk 검증기는 간결한 증명을 생성하고 이를 목표 체인으로 전송하여 검증합니다. 위의 DAO 투표 자격을 예로 들면:

증명자는 제17,000,000 블록이 이더리움 역사에 포함되어 있음을 증명하는 제로 지식 증명을 생성합니다(위의 단계 1).
블록의 유효성을 증명한 후, 우리는 머클 포함 증명(Merkle inclusion proofs)을 사용하여 사용자가 해당 블록이 최종적으로 완료되었을 때 DAO 토큰을 보유하고 있었음을 증명할 수 있습니다(위의 단계 2).

역사 데이터 증명이 크로스 체인 투표를 가능하게 함

그 후, 증명은 목표 체인의 스마트 계약으로 전송되어 검증됩니다. 검증이 성공하면 L2의 스마트 계약은 사용자에게 투표 권한을 부여합니다.

저장 증명을 사용하는 데는 몇 가지 장점이 있습니다. 그 존재로 인해 검증 과정에서 필요하지 않은 것들은 다음과 같습니다:

아카이브 노드 제공업체에 대한 신뢰
프로토콜이 비싼 체인 상 유권자 목록을 유지할 필요 없음
사용자가 자산을 목표 체인으로 이동할 필요 없음

저장 증명에 필요한 설정

지금까지 우리는 저장 증명의 몇 가지 복잡성을 추상화했습니다. 그러나 저장 증명을 사용하려면 서비스 제공업체가 신뢰할 수 없는 제공업체와 함께 사용할 수 있도록 세심한 초기 설정을 해야 합니다. 이 과정의 일환으로, 두 가지가 체인 상에서 생성되고 저장됩니다:

전체 체인의 제로 지식 증명("zk 약속"): 서비스 제공업체는 원본 체인 상의 모든 역사 블록을 머클 트리를 통해 연속적이고 크기가 고정된 "블록"으로 나누고, 각 블록에 대해 제로 지식 증명을 생성하여 그룹을 검증합니다. 그런 다음 이러한 증명을 재귀적으로 병합하여 최종 제로 지식 증명을 얻습니다. 이는 전체 체인에 대한 "zk 약속"입니다. 이는 제공자가 전체 체인의 역사를 올바르게 인덱싱했음을 증명합니다.

이더리움 역사 정보를 기반으로 생성된 zk 약속

머클 마운틴 레인지 데이터 구조: 공급자는 또한 원본 체인의 블록 해시 값(블록)을 그룹화한 Keccak 머클 루트를 "머클 마운틴 레인지(MMR)"라는 체인 상 데이터 구조에 저장합니다. 이 데이터 구조를 사용하는 이유는 쿼리 및 업데이트가 용이하며 제공자가 특정 블록이 체인의 역사에 존재함을 효율적으로 증명할 수 있게 해주기 때문입니다. MMR은 Keccak256 해시 값, 포세이돈 해시 값 또는 두 가지 해시 값을 사용하여 생성됩니다. 포세이돈 해시 값은 제로 지식에 더 친화적이며, 역사 데이터에서 계산을 수행한 후 제로 지식 증명을 통해 데이터 및 계산의 유효성을 증명할 수 있습니다.

머클 마운틴 레인지(MMR)

새로운 블록이 추가됨에 따라 서비스 제공업체는 정기적으로(예: 매시간 또는 매일) "zk 약속" 및 MMR을 업데이트하고 원본 체인과 동기화합니다. 이는 역사 블록이 항상 현재 EVM에서 접근 가능한 256개 블록과 관련이 있도록 유지하기 위한 것입니다. 이는 역사 데이터와 이더리움에서 현재 사용할 수 있는 블록 간의 연관성을 보장합니다.

아래 그림에서는 이 설정을 구현하는 방법을 자세히 설명합니다:

결론적으로, 아래에서는 설정이 완료된 후 저장 증명이 우리가 앞서 소개한 DAO 투표 예제에서 어떻게 구체적으로 작동하는지를 설명합니다:

서비스 공급자는 전체 체인에 대한 "zk 약속"(즉, 이더리움 거래 역사)과 목표 체인에 대한 MMR을 생성하고 저장합니다.
서비스 공급자는 체인 상 또는 체인 외의 역사 데이터를 쿼리할 수 있는 애플리케이션 인터페이스를 제공합니다.
목표 체인上的投票 dApp은 공급자의 스마트 계약에 쿼리를 보내 사용자가 이더리움의 #17,000,000 블록에서 DAO 토큰을 보유하고 있는지 확인합니다.
또한 공급자는 다음을 검증해야 합니다:
쿼리된 블록이 이더리움 역사 기록의 일부인지 확인합니다(위의 단계 1); 이후 MMR을 통해 블록 포함 제로 지식 증명을 생성합니다.
사용자가 #17,000,000 블록에서 DAO 토큰을 보유하고 있는지 확인합니다(위의 단계 2); 그런 다음 공급자는 사용자가 해당 블록 내에서 DAO 토큰을 보유하고 있음을 증명하는 또 다른 제로 지식 증명을 생성합니다.
공급자는 위에서 생성된 증명을 단일 제로 지식 증명으로 집계합니다.
그런 다음 집계된 제로 지식 증명을 목표 체인의 투표 dApp 스마트 계약으로 발송하여 검증하며, 검증이 성공하면 사용자가 투표할 수 있도록 허용합니다.

이 분야에 헌신하는 프로젝트 팀

여러 회사가 신뢰 최소화 방식으로 체인 상 역사 데이터에 접근할 수 있는 스마트 계약을 구축하고 있습니다.

Axiom은 현재 이더리움에서 운영 중이며, zk 기반의 저장 증명을 통해 이더리움의 역사 데이터에 접근할 수 있는 경로를 제공합니다. 이 팀은 또한 역사 데이터를 기반으로 한 체인 외 계산의 능력을 강화하고 있으며, 제로 지식에서 이러한 데이터 및 계산의 정확성을 증명하고 있습니다.

Relic Protocol은 Axiom과 유사한 기술적 접근 방식을 채택하고 있으며, 이더리움 및 zkSync Era에서 운영되고 있습니다. Relic은 머클 포함 증명을 사용하여 데이터 포함을 증명합니다(이는 Axiom이 제로 지식에서 머클 포함을 증명하는 방법과 다릅니다).

Herodotus는 L2에 이더리움 역사 데이터를 제공하기 위해 노력하고 있습니다. 현재 테스트넷은 Starknet 및 zkSync Era에서 운영되고 있습니다. OP 재단의 지원을 받아 Herodotus 팀의 다음 목표는 매우 명확해졌습니다.

Lagrange Labs는 최근 ZK MapReduce(ZKMR) 혁신을 통해 완전히 업데이트 가능한 증명을 도입했습니다. 이는 Recproofs라는 새로운 벡터 약속을 사용하여 업데이트 가능성 개념을 데이터 계산으로 확장합니다.

결론

이번 부분에서는 저장 증명이 제3자에 대한 신뢰 없이 체인 상 역사 데이터를 검증하는 방법을 소개했습니다. 이는 체인 상 구성 및 크로스 체인 상호 운용성의 중요한 도구가 됩니다.

총 가치 잠금이 이더리움에서 두 번째 레이어 생태계로 계속 이동함에 따라, 우리는 저장 증명을 통해 체인 상 역사 데이터를 활용하는 더 표현력 있는 애플리케이션이 등장할 것으로 예상합니다.

제로 지식 증명의 검증 속도가 점점 빨라지고 비용이 점점 저렴해지고 있지만, 체인 상 상태에 맞춰 저장 증명을 지속적으로 생성하는 비용은 여전히 도전 과제가 됩니다. 이러한 서비스의 수익성은 쿼리 애플리케이션에서 발생하는 쿼리 양에 따라 달라질 것입니다.

도전 과제가 있음에도 불구하고, 제로 지식 기술에 의해 구동되는 합의 증명 및 저장 증명의 중요성은 아무리 강조해도 지나치지 않습니다. 우리는 이러한 기술이 더욱 신뢰 최소화된 다중 체인 미래를 구축하는 데 어떻게 사용될지 기대하고 있습니다.