저장 증명에 대한 심층적인 해석: 시간 간 및 체인 간 블록체인 상태 인식 실현
원저자: LongHash Ventures
원본 편집: Deep Chao TechFlow
매시간 기억을 잃어서 사람들에게 자신이 한 일을 말해달라고 끊임없이 요청해야 한다면 어떨까요? 이것이 현재 스마트 계약이 존재하는 곳입니다. 이더리움과 같은 블록체인에서는 스마트 계약이 256개 블록을 초과하는 상태에 직접 액세스할 수 없습니다. 이 문제는 다양한 실행 계층에서 데이터를 검색하고 검증하는 것이 훨씬 더 어려운 다중 체인 생태계에서 더욱 악화됩니다.
2020년 Vitalik Buterin과 Tomasz Stanczak은 시간에 따른 데이터에 액세스하는 방법을 제안했습니다. 이 EIP 솔루션은 정체되었지만 Roll-up을 중심으로 한 멀티체인 세계에서 그 수요가 다시 부각되었습니다. 오늘날 스마트 계약에 대한 인식과 기억을 제공하기 위해 저장 증명이 전면에 등장했습니다.
온체인 데이터에 접근하는 방법
Dapp은 다양한 방법으로 데이터와 상태에 접근할 수 있습니다. 이러한 모든 접근 방식에는 인간/개체, 암호화폐 경제 보안 또는 코드에 대한 애플리케이션의 특정 수준의 신뢰가 필요하며 모두 특정 절충점이 있습니다.
인간/단체를 신뢰하십시오:
아카이브 노드: 운영자는 아카이브 노드를 직접 실행하거나 Alchemy 및 Infura와 같은 아카이브 노드 서비스 제공업체에 의존하여 제네시스 블록부터 시작하는 모든 데이터에 액세스할 수 있습니다. 이는 전체 노드와 동일한 데이터를 제공하지만 전체 블록체인에 대한 모든 기록 상태 데이터도 포함합니다. Etherscan 및 Dune Analytics와 같은 오프체인 서비스는 아카이브 노드를 사용하여 온체인 데이터에 액세스합니다. 오프체인 참가자는 이 데이터의 유효성을 증명할 수 있으며, 온체인 스마트 계약은 데이터가 신뢰할 수 있는 참가자/위원회에 의해 서명되었는지 확인할 수 있습니다. 그러나 기본 데이터의 무결성은 확인할 수 없습니다. 이 접근 방식을 사용하려면 Dapp이 악의적인 의도 없이 올바른 방식으로 인프라를 실행하기 위해 아카이브 노드 서비스 제공자를 신뢰해야 합니다.
암호화폐 경제 보안을 신뢰하십시오:
인덱서: 인덱싱 프로토콜은 블록체인의 모든 데이터를 구성하므로 개발자는 애플리케이션이 쿼리할 수 있도록 개방형 API를 구축하고 게시할 수 있습니다. 개별 인덱서는 인덱싱 및 쿼리 처리 서비스를 제공하기 위해 토큰을 스테이킹하는 노드 운영자입니다. 다만, 제공된 데이터가 부정확할 경우 분쟁이 발생할 수 있으며, 중재절차에 시간이 소요될 수 있습니다. 또한, The Graph와 같은 인덱서의 데이터는 스마트 컨트랙트의 비즈니스 로직에 바로 활용될 수 없으며, web2 기반의 데이터 분석 맥락에서 활용됩니다.
오라클: 오라클 서비스 제공업체는 많은 독립 노드 운영자로부터 집계된 데이터를 사용합니다. 여기서 문제는 오라클에서 얻은 데이터가 자주 업데이트되지 않고 범위가 제한적이라는 것입니다. Chainlink와 같은 오라클은 일반적으로 가격 정보와 같은 특정 상태만 유지하며 애플리케이션별 상태 및 기록 데이터에는 적합하지 않습니다. 또한 이 접근 방식은 데이터에 어느 정도의 편향을 도입하고 노드 운영자에 대한 신뢰가 필요합니다.
신뢰 코드:
특수 변수 및 기능: 이더리움과 같은 블록체인에는 주로 블록체인에 대한 정보를 제공하는 데 사용되는 특수 변수 및 기능이 있거나 일반적인 유틸리티 기능이 있습니다. 스마트 계약은 마지막 256개 블록의 블록 해시에만 액세스할 수 있습니다. 확장성 이유로 인해 모든 블록 해시를 사용할 수 있는 것은 아닙니다. 과거 블록 해시에 접근하면 이에 대한 증거를 확인할 수 있으므로 매우 유용합니다. EVM 실행 환경에는 이전 블록의 내용, 이전 거래 내용 또는 영수증 출력에 액세스할 수 있는 opcode가 없으므로 노드는 이러한 내용을 안전하게 잊어버리고 새 블록을 계속 처리할 수 있습니다. 이 접근 방식은 단일 블록체인으로 제한됩니다.
이러한 솔루션의 과제와 한계를 고려할 때 온체인 저장 및 블록 해시 제공에 대한 분명한 필요성이 있습니다. 보관 증명이 들어오는 곳입니다. 저장 증명을 더 잘 이해하기 위해 블록체인의 데이터 저장을 간단히 살펴보겠습니다.
블록체인의 데이터 저장
블록체인은 네트워크의 많은 컴퓨터에서 업데이트되고 공유되는 공용 데이터베이스입니다. 데이터와 상태는 인접한 블록 그룹에 저장되며, 각 블록은 이전 블록 헤더의 해시를 저장하여 상위 블록을 암호화 방식으로 참조합니다.
이더리움 블록을 예로 들어보겠습니다. 이더리움은 Merkle Patricia Tree(MPT)라는 특별한 Merkle 트리를 사용합니다. 이더리움 블록 헤더에는 상태 트리, 스토리지 트리, 영수증 트리 및 트랜잭션 트리라는 네 가지 Merkle-Patricia 트리의 루트가 포함되어 있습니다. 이 네 개의 트리는 모든 Ethereum 데이터를 포함하는 맵을 인코딩합니다. 머클 트리는 데이터 저장의 효율성 때문에 사용됩니다. 재귀 해싱을 사용하면 결국 루트 해시만 저장하면 되기 때문에 많은 공간이 절약됩니다. 이를 통해 재귀적 해싱 노드가 동일한 루트 해시로 이어진다는 것을 증명함으로써 누구나 트리에 요소의 존재를 증명할 수 있습니다. 머클 증명을 사용하면 이더리움의 라이트 클라이언트가 다음 질문에 답하여 답변을 얻을 수 있습니다.
이 거래가 특정 블록에 존재합니까?
내 계정의 현재 잔액은 얼마입니까?
이 계정이 존재하나요?
모든 거래와 모든 블록을 다운로드하는 대신 라이트 클라이언트는 블록 헤더 체인만 다운로드하고 Merkle 증명을 사용하여 정보를 확인할 수 있습니다. 이는 전체 프로세스를 매우 효율적으로 만듭니다.
Merkle 트리와 관련된 구현, 이점 및 과제를 더 잘 이해하려면 Vitalik 및 Maven 11의 이 블로그 연구 기사를 참조하세요.
보관 증명
저장 증명을 통해 암호화 증명을 사용하여 무언가가 데이터베이스에 기록되었고 유효하다는 것을 증명할 수 있습니다. 그러한 증거를 제공할 수 있다면 블록체인에서 어떤 일이 발생했다는 검증 가능한 진술이 될 것입니다.
보관 증명으로 무엇을 얻을 수 있나요?
보관 증명은 두 가지 주요 기능을 허용합니다.
지난 256개 블록을 넘어 제네시스 블록까지의 과거 온체인 데이터에 액세스하세요.
합의 검증 또는 L2 브리징(L2용)을 통해 한 블록체인에서 다른 블록체인으로의 온체인 데이터(과거 및 현재)에 액세스하세요.
보관 증명은 어떻게 이루어지나요?
간단히 말해서, 저장 증명은 특정 블록이 블록체인의 정식 기록의 일부인지 확인한 다음 요청된 특정 데이터가 블록의 일부인지 확인합니다. 이는 다음을 통해 달성할 수 있습니다.
온체인 처리: Dapp은 초기에 신뢰할 수 있는 블록을 획득하고, 해당 블록을 Calldata로 전달하여 이전 블록에 액세스하고, 처음 블록까지 다시 탐색할 수 있습니다. 이를 위해서는 많은 온체인 계산과 많은 통화 데이터가 필요합니다. 이 접근 방식은 대규모 온체인 계산이 필요하기 때문에 완전히 비실용적입니다. Aragon은 2018년에 온체인 접근 방식을 사용하려고 시도했지만 높은 온체인 비용으로 인해 실현 가능하지 않았습니다.
영지식 증명 사용: 이 접근 방식은 복잡한 계산이 영지식 증명을 사용하여 오프체인으로 이동된다는 점을 제외하면 온체인 처리와 유사합니다.
동일한 체인의 데이터 액세스: 영지식 증명을 사용하여 모든 과거 블록 헤더가 실행 환경에서 액세스할 수 있는 가장 최근의 256개 블록 헤더 중 하나의 조상임을 주장할 수 있습니다. 또 다른 접근 방식은 소스 체인의 전체 기록을 인덱싱하고 영지식 증명을 생성하여 인덱싱이 올바르게 수행되었음을 증명하는 것입니다. 이 증명은 새로운 블록이 소스 체인에 추가됨에 따라 정기적으로 업데이트됩니다.
크로스체인 데이터에 접근: 공급자는 대상 체인의 소스 체인에서 블록 헤더를 수집하고 영지식 합의 증명을 사용하여 이러한 블록 헤더의 유효성을 증명합니다. Axelar, Celer 또는 LayerZero와 같은 기존 크로스체인 메시징 솔루션을 사용하여 블록 헤더를 쿼리할 수도 있습니다.
대상 체인에 있는 소스 체인의 블록 헤더 해시 캐시 또는 오프체인 블록 해시 누적기의 루트 해시를 유지합니다. 이 캐시는 정기적으로 업데이트되며 특정 블록이 존재하고 상태에서 액세스할 수 있는 가장 최근 블록 해시에 대한 암호화 링크가 있음을 온체인에서 효율적으로 증명하는 데 사용됩니다. 이 과정을 체인의 연속성을 증명한다고 합니다. 전용 블록체인을 사용하여 모든 소스 체인의 블록 헤더를 저장하는 것도 가능합니다.
대상 체인에 대한 Dapp의 요청에 따라 기록 데이터/블록은 오프체인 인덱스 데이터 또는 온체인 캐시(요청의 복잡성에 따라 다름)에서 액세스됩니다. 캐시된 블록 헤더 해시는 온체인에 유지되는 반면, 실제 데이터는 오프체인에 저장될 수 있습니다.
Merkle 포함 증명을 통해 특정 블록에 데이터가 존재하는지 확인하고 이에 대한 영지식 증명을 생성합니다. 이 증명은 올바르게 색인된 영지식 증명 또는 영지식 합의 증명과 결합되며 무신뢰 검증을 위해 온체인으로 제공됩니다.
그런 다음 Dapp은 온체인 증명을 확인하고 데이터로 필요한 작업을 수행할 수 있습니다. 영지식 증명을 검증하는 것 외에도 블록 번호 및 블록 해시와 같은 공개 매개변수도 체인에 유지되는 블록 헤더 캐시와 비교하여 확인됩니다.
이 접근 방식을 취하는 프로젝트에는 Herodotus, Lagrange, Axiom, HyperOracle, Brevis Network 및 nil Foundation이 포함됩니다. 여러 블록체인에서 애플리케이션의 상태를 인식하도록 하기 위해 많은 노력이 이루어지고 있는 반면, IBC(Inter-Chain Communication)는 ICQ(Inter-Chain Query) 및 ICA(Cross-chain account)와 같은 기술을 사용하여 애플리케이션을 활성화하는 상호 운용성 표준으로 두각을 나타냅니다. ). ICQ를 사용하면 체인 A의 애플리케이션이 간단한 IBC 패킷에 쿼리를 포함하여 체인 B의 상태를 쿼리할 수 있으며, ICA를 사용하면 한 블록체인이 다른 블록체인의 계정을 안전하게 제어할 수 있습니다. 이들을 결합하면 흥미로운 크로스체인 사용 사례를 지원할 수 있습니다. Saga와 같은 RaaS 제공업체는 기본적으로 IBC를 사용하여 모든 애플리케이션 체인에 이러한 기능을 제공합니다.
스토리지 증명은 메모리 소비, 증명 시간, 검증 시간, 계산 효율성 및 개발자 경험 간의 최상의 균형을 찾기 위해 다양한 방법으로 최적화될 수 있습니다. 전체 프로세스는 대략 3가지 주요 하위 프로세스로 나눌 수 있습니다.
데이터 접근;
데이터 처리;
데이터 접근 및 처리를 위한 영지식 증명 생성.
데이터 액세스: 이 하위 프로세스에서 서비스 제공자는 기본 방식으로 또는 온체인 캐시를 유지하여 실행 계층에서 소스 체인의 블록 헤더에 액세스합니다. 크로스체인 데이터 액세스를 위해서는 소스 체인 합의가 대상 체인에서 검증되어야 합니다. 사용된 방법과 최적화는 다음과 같습니다.
기존 이더리움 블록체인: 이더리움 블록체인의 기존 구조를 사용하여 영지식 증명을 사용하여 현재 블록 헤더와 관련된 모든 기록 저장소 슬롯의 가치를 증명할 수 있습니다. 이는 큰 포함 증거로 간주될 수 있습니다. 즉, 높이 b에 가장 가까운 블록 헤더 X가 주어지면 X의 조상인 높이 bk에 블록 헤더 Y가 있습니다. 이는 이더리움 합의의 보안을 기반으로 하며 효율적인 증명 시스템이 필요합니다. 이것이 Lagrange가 취한 접근 방식입니다.
온체인 머클 산맥(MMR) 캐시: 머클 산맥은 두 나무가 동일한 크기에 도달하면 결합된 머클 트리 목록으로 볼 수 있습니다. MMR의 단일 머클 트리는 트리의 이전 루트에 상위 노드를 추가하여 구성됩니다. MMR은 Merkle 트리와 유사하며 효율적인 요소 추가 및 효율적인 데이터 쿼리, 특히 대규모 데이터 세트에서 순차적 데이터 읽기와 같은 몇 가지 추가 이점이 있습니다. 머클 트리를 통해 새 헤드를 추가하려면 각 수준의 모든 자매 노드를 전달해야 합니다. 데이터를 효율적으로 추가하기 위해 Axiom은 MMR을 사용하여 블록 헤더 해시의 온체인 캐시를 유지합니다. Herodotus는 MMR 블록 해시 누산기의 루트 해시를 온체인에 저장합니다. 이를 통해 증거를 포함하여 이러한 블록 헤더 해시와 비교하여 가져온 데이터를 확인할 수 있습니다. 이 접근 방식에는 정기적인 캐시 업데이트가 필요하므로 분산되지 않으면 활성 문제가 발생할 수 있습니다.
효율성과 계산 비용을 최적화하기 위해 Herodotus는 두 가지 다른 MMR을 유지합니다. 특정 블록체인이나 레이어에 따라 누산기는 다양한 해시 함수로 맞춤화될 수 있습니다. Starknet을 증명할 때 포세이돈 해시를 사용할 수 있지만 EVM 체인에는 Keccack 해시를 사용할 수 있습니다.
오프체인 MMR 캐시: Herodotus는 데이터가 다시 요청될 때 더 빨리 얻을 수 있도록 이전에 얻은 쿼리와 결과의 오프체인 캐시를 유지합니다. 이를 위해서는 단순히 아카이브 노드를 실행하는 것보다 더 많은 인프라가 필요합니다. 오프체인 인프라의 최적화는 최종 사용자의 비용을 잠재적으로 줄일 수 있습니다.
저장을 위한 전용 블록체인: Brevis는 입증된 모든 체인에 대한 모든 블록 헤더를 저장하기 위해 전용 영지식 롤업(집계 레이어)을 사용합니다. 이 집계 계층이 없으면 각 체인은 다른 모든 체인의 블록 헤더를 저장해야 하며, 이로 인해 N개의 블록체인에 대해 O(N 2) 연결이 발생하게 됩니다. 집계 레이어를 도입함으로써 각 블록체인은 롤업의 상태 루트만 저장하면 되므로 전체 연결이 O(N)으로 줄어듭니다. 이 레이어는 여러 블록 헤더/쿼리 결과 증명을 집계하고 연결된 각 블록체인에 단일 확인 증명을 제출하는 데에도 사용됩니다.
L1-L2 메시징: L2는 L1을 통해 L2 계약을 업데이트하기 위한 기본 메시징을 지원하므로 소스 체인 합의 확인을 피할 수 있습니다. 캐시는 이더리움에서 업데이트될 수 있으며, L1-L2 메시징을 사용하여 오프체인 컴파일된 블록 해시 또는 트리 루트를 다른 L2에 보낼 수 있습니다. Herodotus는 이 접근 방식을 취하고 있지만 Alt L1에서는 실현 가능하지 않습니다.
데이터 처리:
데이터에 접근하는 것 외에도 스마트 계약은 데이터에 대해 임의의 계산을 수행할 수 있어야 합니다. 일부 사용 사례에서는 계산이 필요하지 않을 수도 있지만, 다른 많은 경우에는 중요한 부가가치 서비스입니다. 많은 서비스 제공업체는 영지식 증명 형태로 데이터에 대한 계산을 지원하고 이 증명을 온체인으로 제공하여 유효성을 확인합니다. Axelar, LayerZero 및 Polyhedra Network와 같은 기존 크로스체인 메시징 솔루션이 데이터 액세스에 사용될 수 있으므로 데이터 처리는 스토리지 증명 서비스 제공업체의 차별화 포인트가 될 수 있습니다.
예를 들어 HyperOracle을 사용하면 개발자는 JavaScript를 사용하여 맞춤형 오프체인 계산을 정의할 수 있습니다. Brevis는 Dapp의 데이터 쿼리를 받아들이고 검증된 블록 헤더를 사용하여 이를 처리하는 개방형 영지식 쿼리 엔진 시장을 설계했습니다. 스마트 계약은 시장의 증명자가 얻은 데이터 쿼리를 보냅니다. 증명자는 쿼리 입력, 관련 블록 헤더(Brevis 집계 계층의) 및 결과를 기반으로 증명을 생성합니다. Lagrange는 SQL, MapReduce 및 Spark/RDD와 같은 검증된 분산 프로그래밍 모델을 위한 영지식 빅 데이터 기술 스택을 도입합니다. 이러한 증명은 모듈식이며 기존 크로스체인 브리징 및 크로스체인 메시징 프로토콜의 모든 블록 헤더에서 생성될 수 있습니다. Lagrange의 영지식 빅데이터 기술 스택의 첫 번째 제품은 대량의 다중 체인 데이터와 관련된 계산 결과를 증명하는 데 사용되는 분산 컴퓨팅 엔진(유명한 MapReduce 프로그래밍 모델 기반)인 영지식 MapReduce입니다. 예를 들어, 단일 영지식 MapReduce 증명은 지정된 시간 내에 4~5개 체인에 배포된 DEX의 유동성 변화를 증명할 수 있습니다. 상대적으로 간단한 쿼리의 경우 현재 헤로도토스처럼 온체인에서 직접 계산을 수행할 수도 있습니다.
증명 생성:
재생 가능 증명: 재생 가능 증명은 증명을 계산하고 움직이는 블록 스트림을 통해 효율적으로 유지 관리해야 할 때 사용할 수 있습니다. 새로운 블록이 생성되면 계약 변수(예: 토큰 가격)의 이동 평균 증명을 유지하기 위해 처음부터 새로운 증명을 다시 계산할 필요 없이 기존 증명을 효율적으로 업데이트할 수 있습니다. 온체인 상태의 동적 데이터 병렬 계산을 증명하기 위해 Lagrange는 MPT의 일부 위에 Recproof라는 배치 벡터 커밋을 구축하고 이를 실시간으로 업데이트하고 동적으로 계산했습니다. MPT 위에 Verkle 트리를 반복적으로 생성함으로써 Lagrange는 대량의 동적 온체인 상태 데이터를 효율적으로 계산할 수 있습니다.
Verkle 트리: 상위 노드를 공유하는 모든 노드가 필요한 Merkle 트리와 달리 Verkle 트리에는 루트 경로만 필요합니다. 이 경로는 Merkle 트리의 모든 자매 노드에 비해 훨씬 작습니다. Ethereum은 또한 Ethereum 전체 노드가 보유해야 하는 상태의 양을 최소화하기 위해 향후 버전에서 Verkle 트리를 사용하는 것을 고려하고 있습니다. Brevis는 Verkle 트리를 사용하여 검증된 블록 헤더와 쿼리 결과를 집계 계층에 저장합니다. 특히 트리에 많은 수의 요소가 포함되어 있는 경우 데이터 포함 증명의 크기를 크게 줄이고 대량 데이터에 대한 효율적인 포함 증명을 지원합니다.
증명 생성 속도를 높이기 위한 메모리 풀 모니터링: Herodotus는 최근 터보를 출시했습니다. 이를 통해 개발자는 스마트 계약 코드에 몇 줄의 코드를 추가하여 데이터 쿼리를 지정할 수 있습니다. Herodotus는 터보 계약과 상호 작용하는 스마트 계약 거래의 멤풀을 모니터링합니다. 증명 생성 프로세스는 트랜잭션이 멤풀 자체에 있을 때 시작됩니다. 온체인에서 증거가 생성되고 검증되면 결과가 온체인 터보 교환 계약에 기록됩니다. 보관 증명을 통한 인증 후에만 결과가 터보 교환 계약에 기록될 수 있습니다. 이런 일이 발생하면 거래 수수료의 일부가 시퀀서 또는 블록 생성기와 공유되어 수수료가 징수될 때까지 더 오래 기다리도록 유도합니다. 간단한 데이터 쿼리의 경우 사용자의 거래가 블록에 포함되기 전에 요청한 데이터가 이미 온체인에서 사용 가능할 수 있습니다.
상태/보관 증명 적용
상태 증명 및 스토리지는 애플리케이션, 미들웨어 및 인프라 계층에서 스마트 계약에 대한 많은 새로운 사용 사례를 열어줄 수 있습니다. 그 중 일부는 다음과 같습니다:
애플리케이션 계층:
통치:
크로스체인 투표: 온체인 투표 프로토콜을 통해 체인 B의 사용자는 체인 A의 자산 소유권을 증명할 수 있습니다. 사용자는 새로운 체인에 대한 투표권을 얻기 위해 자산을 연결할 필요가 없습니다. 예: Herodotus의 SnapshotX
거버넌스 토큰 배포: 애플리케이션은 활성 사용자나 얼리 어답터에게 더 많은 거버넌스 토큰을 배포할 수 있습니다. 예: Lagrange의 RetroPGF.
정체성과 평판:
소유권 증명: 사용자는 체인 B에서 특정 작업을 수행하기 위해 체인 A의 특정 NFT, SBT 또는 자산을 소유하고 있음을 증명할 수 있습니다. 예를 들어, 게임 애플리케이션 체인은 Ethereum이나 L2와 같은 기존 유동성을 갖춘 다른 체인에서 NFT 컬렉션을 출시하기로 결정할 수 있습니다. 이를 통해 게임은 실제로 크로스체인 NFT를 요구하지 않고도 다른 곳에 존재하는 유동성을 활용할 수 있습니다.
사용 증명: 사용자는 플랫폼에서의 과거 사용량을 기반으로 할인이나 프리미엄 기능을 받을 수 있습니다(사용자가 Uniswap에서 X 금액을 거래했다는 증거).
OG 증명: 사용자는 X일 이상 된 활성 계정을 가지고 있음을 증명할 수 있습니다.
온체인 신용 점수: 크로스체인 신용 점수 플랫폼은 단일 사용자의 여러 계정에서 데이터를 집계하여 신용 점수를 생성할 수 있습니다.
위의 모든 증명은 사용자에게 맞춤형 경험을 제공하는 데 사용될 수 있습니다. Dapp은 숙련된 거래자나 사용자를 유지하기 위해 할인이나 특권을 제공하고 초보 사용자에게 간소화된 사용자 경험을 제공할 수 있습니다.
Defi:
크로스체인 대출: 사용자는 브리징 토큰 없이 체인 A의 자산을 잠그고 체인 B에서 대출을 받을 수 있습니다.
온체인 보험: 과거 온체인 데이터에 액세스하여 실패 여부를 판단할 수 있으며, 보험 보상은 전적으로 체인에서 완료될 수 있습니다.
풀에 있는 자산의 시간 가중 평균 가격: 애플리케이션은 지정된 기간 내에 AMM 풀에 있는 자산의 평균 가격을 계산하고 얻을 수 있습니다. 예: Axiom의 Uniswap TWAP oracle.
옵션 가격 책정: 온체인 옵션 프로토콜은 분산형 거래소의 지난 n 블록에 대한 자산의 변동성을 사용하여 옵션 가격을 책정할 수 있습니다.
마지막 두 가지 사용 사례에서는 소스 체인에 새 블록이 추가될 때 증명을 업데이트해야 합니다.
미들웨어:
의도: 증명을 저장하면 사용자가 의도를 더욱 표현하고 명시적으로 표현할 수 있습니다. 솔버의 임무는 사용자의 의도를 만족시키기 위해 필요한 단계를 수행하는 것이지만, 사용자는 온체인 데이터 및 매개변수를 기반으로 조건을 보다 명확하게 지정할 수 있습니다. 또한 솔버는 최적의 솔루션을 찾는 데 활용되는 온체인 데이터의 유효성을 입증할 수도 있습니다.
계정 추상화: 사용자는 저장 증명을 활용하여 다른 체인의 데이터를 기반으로 규칙을 설정할 수 있습니다. 예를 들어 모든 지갑에는 nonce가 있습니다. 1년 전에는 nonce가 특정 숫자였고 현재 nonce는 동일하다는 것을 보여줄 수 있습니다. 이를 통해 해당 지갑이 전혀 사용되지 않았음을 증명할 수 있으며, 해당 지갑에 대한 접근 권한을 다른 지갑에 위임할 수 있습니다.
온체인 자동화: 스마트 계약은 온체인 데이터에 의존하는 사전 정의된 조건에 따라 특정 작업을 자동으로 수행할 수 있습니다. 자동화된 프로그램은 AMM에 대한 최적의 가격 흐름을 유지하거나 악성 부채를 방지하여 대출 프로토콜을 건전하게 유지하기 위해 스마트 계약을 정기적으로 호출해야 합니다. HyperOracle은 자동화 및 온체인 데이터 액세스를 지원합니다.
하부 구조
무신뢰 온체인 오라클: 오라클 네트워크 내 여러 개별 오라클 노드의 응답을 집계하는 분산형 오라클 네트워크입니다. Oracle 네트워크는 이러한 중복성을 제거하고 암호화 보안을 활용하여 온체인 데이터를 활성화할 수 있습니다. 오라클 네트워크는 여러 체인(L1, L2 및 Alt L1)의 데이터를 단일 체인으로 집계하고 저장 증명을 사용하여 다른 곳에 존재함을 증명할 수 있습니다. 상당한 발전을 이루고 있는 DeFi 솔루션도 맞춤형 솔루션을 사용할 수 있습니다. 예를 들어, 최대 유동성 스테이킹 제공업체인 Lido Finance는 Nil Foundation과 제휴하여 zkOracle 개발 자금을 지원했습니다. 이러한 솔루션은 EVM 기록 데이터에 대한 무신뢰 데이터 액세스를 가능하게 하고 Lido Finance의 150억 달러에 달하는 이더리움 유동성을 보호합니다.
크로스체인 메시징 프로토콜: 기존 크로스체인 메시징 솔루션은 저장 증명 서비스 제공자와 제휴하여 메시지의 표현력을 높일 수 있습니다. 이는 Lagrange가 모듈화 논문에서 제안한 접근 방식입니다.
결론적으로
인식을 통해 기술 회사는 고객에게 더 나은 서비스를 제공할 수 있습니다. 사용자 신원부터 구매 행동, 사회적 연결에 이르기까지 기술 회사는 인지 기능을 사용하여 정확한 타겟팅, 고객 세분화, 바이럴 마케팅과 같은 기능을 활용합니다. 전통적인 기술 회사는 사용자의 명시적인 허가를 요구하며 사용자 데이터를 관리할 때 주의를 기울여야 합니다. 그러나 허가된 블록체인의 모든 사용자 데이터는 공개되며 반드시 사용자 신원을 공개하지는 않습니다. 스마트 계약은 공개적으로 사용 가능한 데이터를 활용하여 사용자에게 더 나은 서비스를 제공할 수 있어야 합니다. 더욱 전문화된 생태계의 개발과 채택으로 인해 시간과 체인 전반에 걸친 상태 인식이 점점 더 중요한 문제가 될 것입니다. 저장 증명을 통해 이더리움은 단순한 결제 계층이 아닌 신원 및 자산 소유권 계층으로 등장할 수 있습니다. 사용자는 자산을 항상 연결할 필요 없이 여러 블록체인에서 사용할 수 있는 이더리움에서 자신의 신원과 주요 자산을 유지할 수 있습니다. 우리는 앞으로 펼쳐질 새로운 가능성과 사용 사례에 대해 계속 기대하고 있습니다.


