
시간을 초월한 저장 증명: 블록체인 상태 인식의 다중 체인 확장
작성: LongHash Ventures
번역: TechFlow
매시간마다 기억을 잃고, 자신이 무엇을 했는지 계속해서 다른 사람에게 물어봐야 한다면 어떻게 할 것인가? 이것이 바로 현재 스마트 계약이 처한 상황이다. 이더리움과 같은 블록체인에서 스마트 계약은 256개 이상의 블록을 초과하는 상태에 직접 접근할 수 없다. 이 문제는 멀티체인 생태계에서 더욱 심각해지며, 서로 다른 실행 계층 간 데이터 검색 및 검증은 훨씬 더 어렵다.
2020년, 비탈릭 부테린(Vitalik Buterin)과 토마시 스탄차크(Tomasz Stanczak)는 시간을 초월해 데이터에 접근하는 방법을 제안했다. 이 EIP 제안은 결국 중단되었지만, 롤업 중심의 멀티체인 세계에서 그 필요성이 다시 부상하고 있다. 오늘날 저장 증명(proof of storage)은 스마트 계약에 인식 능력과 기억력을 부여하기 위한 최전선 기술로 떠올랐다.
체인상 데이터 접근 방식
Dapp은 다양한 방식으로 데이터와 상태에 접근할 수 있다. 이러한 모든 방법은 애플리케이션이 인간/엔터티, 암호경제적 보안성 또는 코드에 대해 어느 정도의 신뢰를 요구하며, 각각 장단점이 존재한다.

신뢰 대상: 인간/엔터티
아카이브 노드: 운영자는 자체적으로 아카이브 노드를 운영하거나 Alchemy, Infura 등의 아카이브 노드 서비스 제공업체에 의존하여 창세 블록부터 모든 데이터에 접근할 수 있다. 아카이브 노드는 전체 노드와 동일한 데이터를 제공할 뿐 아니라 블록체인의 전체 역사적 상태 데이터도 포함한다. Etherscan 및 Dune Analytics와 같은 오프체인 서비스는 아카이브 노드를 활용해 체인상 데이터에 접근한다. 오프체인 참여자들은 이러한 데이터의 유효성을 입증할 수 있으며, 체인상 스마트 계약은 해당 데이터가 신뢰할 수 있는 참여자/위원회에 의해 서명되었는지를 검증할 수 있다. 그러나 기본 데이터의 무결성은 검증할 수 없다. 이 방법은 Dapp이 아카이브 노드 제공자가 정확하고 악의 없이 인프라를 운영한다고 믿어야 하므로, 일정 수준의 신뢰를 요구한다.
신뢰 대상: 암호경제적 보안성
-
인덱서: 인덱싱 프로토콜은 블록체인상 모든 데이터를 조직화하여 개발자가 공개 API를 구축하고 게시할 수 있게 하며, 이를 통해 애플리케이션이 쿼리를 수행할 수 있다. 개별 인덱서는 인덱싱 및 쿼리 처리 서비스를 제공하기 위해 토큰을 스테이킹하는 노드 운영자이다. 하지만 제공된 데이터가 잘못된 경우 분쟁이 발생할 수 있으며, 중재 과정에는 시간이 소요된다. 또한 The Graph와 같은 인덱서로부터 얻은 데이터는 스마트 계약의 비즈니스 로직에 직접 활용될 수 없으며, 웹2 기반의 데이터 분석 맥락에서 사용된다.
-
오라클: 오라클 서비스 제공업체는 여러 독립된 노드 운영자로부터 수집한 데이터를 집계한다. 여기서 문제는 오라클로부터 얻는 데이터가 자주 업데이트되지 않거나 범위가 제한적이라는 점이다. 체인링크(Chainlink)와 같은 오라클은 일반적으로 가격 정보와 같은 특정 상태만 유지하며, 애플리케이션 특화 상태나 역사적 데이터에는 적합하지 않다. 또한 이 방법은 노드 운영자들을 신뢰해야 하므로 데이터에 일정한 편향이 유입될 가능성이 있다.
신뢰 대상: 코드
특수 변수 및 함수: 이더리움과 같은 블록체인은 블록체인 정보 제공이나 일반적인 유틸리티 기능을 위한 특수 변수와 함수를 갖추고 있다. 스마트 계약은 최근 256개 블록까지만 블록 해시에 접근할 수 있다. 확장성을 이유로 모든 블록의 블록 해시를 사용 가능한 것은 아니다. 역사적 블록 해시에 접근할 수 있다면 매우 유용할 것이다. 왜냐하면 이를 통해 해당 블록에 대한 증명을 검증할 수 있기 때문이다. EVM 실행 환경에는 오래된 블록 내용, 이전 거래 내용 또는 영수증 출력에 접근할 수 있는 연산코드(opcode)가 없으므로, 노드는 이러한 내용을 안전하게 '잊어버릴' 수 있으며 여전히 새로운 블록을 처리할 수 있다. 이 방법은 또한 단일 블록체인에 국한된다.
이러한 솔루션들의 도전과 한계를 고려할 때, 블록 해시를 체인상에 저장하고 제공하려는 명확한 수요가 존재함을 알 수 있다. 바로 여기서 저장 증명이 등장한다. 저장 증명을 더 잘 이해하기 위해 먼저 블록체인 내 데이터 저장 방식을 살펴보자.
블록체인 내 데이터 저장
블록체인은 네트워크 내 다수의 컴퓨터 사이에서 업데이트되고 공유되는 공공 데이터베이스이다. 데이터와 상태는 연속적인 블록 단위로 저장되며, 각 블록은 부모 블록의 헤더 해시를 저장함으로써 암호학적으로 이를 참조한다.
이더리움 블록을 예로 들어보자. 이더리움은 "머클 패트리샤 트리(Merkle Patricia Tree, MPT)"라고 불리는 특수한 머클 트리를 사용한다. 이더리움 블록 헤더는 상태 트리, 저장 트리, 영수증 트리, 거래 트리라는 네 가지 다른 머클-패트리샤 트리의 루트를 포함한다. 이 네 개의 트리는 이더리움의 모든 데이터를 포함하는 매핑을 인코딩한다. 머클 트리는 데이터 저장의 효율성 때문에 사용된다. 재귀적 해싱을 통해 최종적으로 루트 해시만 저장하면 되므로 많은 공간을 절약할 수 있다. 누구라도 재귀적으로 해싱된 노드들이 동일한 루트 해시로 이어지는 것을 증명함으로써 트리 내 요소의 존재를 입증할 수 있다. 머클 증명을 통해 이더리움의 경량 클라이언트(light client)는 다음 질문들에 답할 수 있다.
-
이 거래는 특정 블록에 존재하는가?
-
내 계정의 현재 잔액은 얼마인가?
-
이 계정은 존재하는가?
모든 거래와 모든 블록을 다운로드하는 대신, '경량 클라이언트'는 블록 헤더 체인만 다운로드하고 머클 증명을 사용해 정보를 검증할 수 있다. 이는 전체 프로세스를 매우 효율적으로 만든다.
머클 트리 관련 구현, 장점 및 도전 과제에 대해 더 깊이 이해하려면 비탈릭과 Maven11의 이 블로그 연구 글을 참고하라.
저장 증명 (Proof of Storage)
저장 증명은 암호학적 증명을 사용해 어떤 사항이 데이터베이스에 기록되어 있고 유효하다는 것을 입증할 수 있게 해준다. 만약 우리가 그러한 증명을 제공할 수 있다면, 이는 블록체인에서 어떤 일이 실제로 발생했음을 검증 가능한 진술로 만들 수 있다.
저장 증명이 가능하게 하는 것은 무엇인가?
저장 증명은 두 가지 주요 기능을 가능하게 한다.
-
최근 256개 블록을 넘어 창세 블록까지의 역사적 체인상 데이터에 접근
-
다른 블록체인의 체인상 데이터(역사적 및 현재 데이터)를 하나의 블록체인에서 접근, 합의 검증 또는 L2 브릿지(L2 전용) 활용
저장 증명은 어떻게 작동하는가?
간단히 말해, 저장 증명은 특정 블록이 블록체인의 공식 역사 일부인지 확인한 후, 요청된 특정 데이터가 그 블록의 일부인지 검증한다. 이는 다음과 같은 방식으로 달성된다.
-
체인상 처리: Dapp은 신뢰할 수 있는 초기 블록을 가져와 calldata로 블록을 전달하면서 창세 블록까지 거슬러 올라가는 방식으로 이전 블록에 접근할 수 있다. 이는 엄청난 양의 체인상 계산과 많은 calldata를 필요로 한다. 체인상 계산이 방대하기 때문에 이 방법은 전혀 실용적이지 않다. Aragon은 2018년 체인상 방법을 시도했지만 높은 체인상 비용으로 인해 실패했다.
-
제로 지식 증명 사용: 체인상 처리와 유사하지만, 복잡한 계산을 오프체인으로 이전하기 위해 제로 지식 증명을 사용한다는 점에서 차이가 있다.
동일 체인 데이터 접근: 제로 지식 증명을 사용해 최근 256개의 접근 가능한 블록 헤더 중 하나의 조상임을 주장할 수 있다. 또 다른 방법은 소스 체인의 전체 역사를 인덱싱하고 인덱싱이 올바르게 수행되었음을 입증하는 제로 지식 증명을 생성하는 것이다. 이 증명은 소스 체인에 새로운 블록이 추가될 때마다 정기적으로 업데이트된다.
-
교차 체인 데이터 접근: 제공자는 타겟 체인에 소스 체인의 블록 헤더를 수집하고 제로 지식 합의 증명을 사용해 이 블록 헤더의 유효성을 입증한다. Axelar, Celer, LayerZero와 같은 기존의 교차 체인 메시지 전달 솔루션을 사용해 블록 헤더를 조회할 수도 있다.
-
타겟 체인에 소스 체인의 블록 헤더 해시 캐시를 유지하거나, 오프체인 블록 해시 누산기의 루트 해시를 유지한다. 이 캐시는 정기적으로 업데이트되어, 주어진 블록이 존재하고 체인상에서 접근 가능한 최근 블록 해시와 암호학적으로 연결되어 있음을 체인상에서 효율적으로 입증하는 데 사용된다. 이 과정을 '체인 연속성 증명'이라고 한다. 모든 소스 체인의 블록 헤더를 저장하기 위해 전용 블록체인을 사용할 수도 있다.
-
타겟 체인에서 Dapp의 요청에 따라 오프체인 인덱스 데이터 또는 체인상 캐시(요청의 복잡성에 따라)에서 역사적 데이터/블록에 접근한다. 캐시된 블록 헤더 해시는 체인상에 유지되지만 실제 데이터는 오프체인에 저장될 수 있다.
-
머클 포함 증명을 통해 지정된 블록에 데이터가 존재하는지 확인하고, 이를 위한 제로 지식 증명을 생성한다. 이 증명은 올바르게 인덱싱된 제로 지식 증명 또는 제로 지식 합의 증명과 결합되어 체인상에서 신뢰 없이 검증 가능하도록 제공된다.
-
그 후 Dapp은 체인상에서 이 증명을 검증하고 데이터를 사용해 필요한 작업을 수행할 수 있다. 제로 지식 증명 검증 외에도 블록 번호 및 블록 해시와 같은 공개 매개변수도 체인상에 유지되는 블록 헤더 캐시와 함께 검사된다.
이러한 방법을 채택한 프로젝트로는 Herodotus, Lagrange, Axiom, HyperOracle, Brevis Network, nil 재단 등이 있다. 애플리케이션이 여러 블록체인에 걸쳐 상태 인식을 갖도록 하기 위한 노력이 활발하지만, IBC(Inter-Blockchain Communication)는 상호 운용성 표준으로 부상하며 ICQ(교차 체인 쿼리) 및 ICA(교차 체인 계정)와 같은 기능을 지원한다. ICQ를 통해 체인 A의 애플리케이션은 간단한 IBC 패킷에 쿼리를 포함해 체인 B의 상태를 조회할 수 있으며, ICA는 한 블록체인이 다른 블록체인의 계정을 안전하게 제어할 수 있도록 한다. 이들을 조합하면 흥미로운 교차 체인 사례를 지원할 수 있다. Saga와 같은 RaaS 제공업체는 모든 앱체인에 기본적으로 IBC를 적용해 이러한 기능을 제공한다.
저장 증명은 메모리 소비, 증명 시간, 검증 시간, 계산 효율성 및 개발자 경험 사이에서 최적의 균형을 찾기 위해 다양한 방식으로 최적화될 수 있다. 전체 프로세스는 대략적으로 세 가지 주요 하위 프로세스로 나눌 수 있다.
-
데이터 접근;
-
데이터 처리;
-
데이터 접근 및 처리에 대한 제로 지식 증명 생성.

데이터 접근: 이 하위 프로세스에서 서비스 제공자는 실행 계층에서 소스 체인의 블록 헤더에 네이티브 방식으로 접근하거나 체인상 캐시를 유지함으로써 접근한다. 교차 체인 데이터 접근의 경우 타겟 체인에서 소스 체인 합의를 검증해야 한다. 채택된 방법과 최적화는 다음과 같다.
-
기존 이더리움 블록체인: 이더리움 블록체인의 기존 구조를 활용해 현재 블록 헤더에 대한 임의의 역사적 저장 슬롯 값을 증명하는 제로 지식 증명을 사용할 수 있다. 이것은 큰 포함 증명으로 볼 수 있다. 즉, 높이 b에서 최근 블록 헤더 X가 있고, 높이 b-k에서 X의 조상인 블록 헤더 Y가 존재한다는 것이다. 이는 이더리움 합의의 보안성에 기반하며, 효율적인 증명 시스템이 필요하다. Lagrange가 채택한 방법이다.
-
체인상 머클 마운틴 레인지(MMR) 캐시: 머클 마운틴 레인지는 크기가 같은 두 트리가 결합될 때의 머클 트리 리스트로 볼 수 있다. MMR 내 개별 머클 트리는 이전 루트에 부모 노드를 추가함으로써 결합된다. MMR은 머클 트리와 유사하지만, 요소를 효율적으로 추가하고 특히 대규모 데이터셋에서 순차적 데이터를 효율적으로 읽어오는 등 추가적인 장점이 있다. 머클 트리에 새 헤더를 추가하려면 모든 레벨에서 모든 자매 노드를 전달해야 한다. 데이터를 효율적으로 추가하기 위해 Axiom은 MMR을 사용해 체인상에 블록 헤더 해시 캐시를 유지한다. Herodotus는 MMR 블록 해시 누산기의 루트 해시를 체인상에 저장한다. 이를 통해 획득한 데이터가 이러한 블록 헤더 해시와 포함 증명을 통해 일치하는지 확인할 수 있다. 이 방법은 캐시를 정기적으로 업데이트해야 하며, 탈중앙화되지 않을 경우 활성 문제(liveness issue)가 발생할 수 있다.
-
효율성과 계산 비용을 최적화하기 위해 Herodotus는 두 가지 다른 MMR을 유지한다. 특정 블록체인 또는 계층에 따라 누산기는 다른 해시 함수로 맞춤화될 수 있다. Starknet에 대한 증명에는 poseidon 해시를 사용할 수 있지만, EVM 체인에는 Keccak 해시를 사용한다.
-
오프체인 MMR 캐시: Herodotus는 이전에 조회한 쿼리 및 결과를 오프체인에 캐시하여 데이터 재요청 시 더 빠르게 접근할 수 있도록 한다. 이는 아카이브 노드를 운영하는 것보다 더 많은 인프라를 필요로 한다. 오프체인 인프라에 대한 최적화는 궁극적으로 최종 사용자의 비용을 줄일 수 있다.
-
저장을 위한 전용 블록체인: Brevis는 모든 체인의 모든 블록 헤더를 저장하기 위해 전용 제로 지식 롤업(집계 계층)에 의존한다. 이 집계 계층이 없다면 각 체인은 다른 모든 체인의 블록 헤더를 저장해야 하며, N개의 블록체인에 대해 O(N²)의 '연결'이 필요하게 된다. 집계 계층을 도입하면 각 체인은 롤업의 상태 루트만 저장하면 되므로 전체 연결을 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의 유동성 변화를 입증할 수 있다. 비교적 간단한 쿼리의 경우, Herodotus가 현재 하고 있는 것처럼 직접 체인상에서 계산을 수행할 수도 있다.
증명 생성:
-
갱신 가능한 증명: 이동하는 블록 스트림에 대해 계산하고 증명을 효율적으로 유지관리해야 할 때 사용된다. 새로운 블록이 생성될 때마다, 계약 변수(예: 토큰 가격)의 이동 평균 증명을 유지하기 위해 기존 증명을 효율적으로 업데이트할 수 있으며, 처음부터 새로운 증명을 다시 계산할 필요가 없다. 체인상 상태의 동적 데이터 병렬 계산을 증명하기 위해 Lagrange는 MPT 일부 위에 Recproof라 불리는 일괄 벡터 커밋먼트를 구축하고 실시간으로 업데이트하며 동적 계산을 수행한다. MPT 위에 재귀적으로 Verkle 트리를 생성함으로써 Lagrange는 대량의 동적 체인상 상태 데이터를 효율적으로 계산할 수 있다.
-
Verkle 트리: 머클 트리는 공유 부모 노드의 모든 자매 노드를 제공해야 하지만, Verkle 트리는 루트 경로만 필요로 한다. 이 경로는 머클 트리의 자매 노드들에 비해 훨씬 작다. 이더리움도 미래 버전에서 Verkle 트리를 사용해 전체 노드가 보유해야 하는 상태량을 최소화하려고 고려하고 있다. Brevis는 집계 계층에 증명된 블록 헤더와 쿼리 결과를 저장하기 위해 Verkle 트리를 활용한다. 이는 특히 트리에 많은 요소가 포함될 때 데이터 포함 증명의 크기를 크게 줄이며, 대량 데이터의 효율적인 포함 증명을 지원한다.
-
메모리풀 감시를 통한 증명 생성 가속: Herodotus는 최근 turbo를 출시해, 개발자가 스마트 계약 코드에 몇 줄의 코드를 추가해 데이터 쿼리를 지정할 수 있도록 했다. Herodotus는 turbo 계약과 상호작용하는 스마트 계약 거래의 메모리풀을 감시한다. 거래가 메모리풀에 있을 때 이미 증명 생성 프로세스가 시작된다. 증명이 체인상에서 생성 및 검증되면 결과가 체인상 turbo 스왑 계약에 기록된다. 저장 증명을 통해 인증된 후에야 결과가 turbo 스왑 계약에 기록될 수 있다. 이 경우 발생한 거래 수수료 일부는 정렬자(orderer) 또는 블록 생성자와 공유되며, 이는 수수료를 받기 위해 더 오랫동안 기다리도록 유도한다. 간단한 데이터 쿼리의 경우, 사용자의 거래가 블록에 포함되기 전에 요청한 데이터가 이미 체인상에서 이용 가능할 수 있다.
상태/저장 증명의 응용
상태 및 저장 증명은 애플리케이션 계층, 미들웨어, 인프라 계층의 스마트 계약에 수많은 새로운 사용 사례를 열어줄 수 있다. 그 일부는 다음과 같다.
애플리케이션 계층:
거버넌스:
-
교차 체인 투표: 체인상 투표 프로토콜을 통해 체인 B의 사용자가 체인 A에서 자산을 소유하고 있음을 증명할 수 있다. 사용자는 새로운 체인에서 투표권을 얻기 위해 자산을 브릿징할 필요가 없다. 예: Herodotus 상의 SnapshotX
-
거버넌스 토큰 배분: 앱은 활성 사용자나 초기 채택자에게 더 많은 거버넌스 토큰을 배분할 수 있다. 예: Lagrange 상의 RetroPGF
신원 및 평판:
-
소유권 증명: 사용자는 체인 A에서 특정 NFT, SBT 또는 자산을 소유하고 있음을 증명함으로써 체인 B에서 특정 작업을 수행할 수 있다. 예를 들어, 게임 앱체인은 이더리움이나 기타 L2와 같이 기존 유동성을 가진 다른 체인에서 NFT 컬렉션을 시작할 수 있다. 이를 통해 실제로 NFT를 교차 체인하지 않고도 다른 곳의 유동성을 활용할 수 있다.
-
사용 증명: 사용자는 플랫폼에서의 과거 사용 이력(Uniswap에서 X량 거래)에 따라 할인 또는 고급 기능을 받을 수 있다.
-
OG 증명: 사용자는 자신의 계정이 X일 이상 활성화된 계정임을 증명할 수 있다.
-
체인상 신용 점수: 교차 체인 신용 점수 플랫폼은 개별 사용자의 여러 계정 데이터를 집계해 신용 점수를 생성할 수 있다.
위의 모든 증명은 사용자에게 맞춤형 경험을 제공하는 데 활용될 수 있다. Dapp은 숙련된 트레이더나 사용자를 유지하기 위해 할인이나 특전을 제공하거나, 초보자 사용자를 위해 단순화된 사용자 경험을 제공할 수 있다.
DeFi:
-
교차 체인 대출: 사용자는 체인 A에 자산을 담보로 맡기고 체인 B에서 대출을 받을 수 있으며, 토큰을 브릿징할 필요가 없다.
-
체인상 보험: 역사적 체인상 데이터 접근을 통해 고장을 판단하고, 보험 지급을 완전히 체인상에서 처리할 수 있다.
-
풀 내 자산의 시간가중평균가격(TWAP): 앱은 지정된 기간 동안 AMM 풀 내 자산의 평균 가격을 계산하고 가져올 수 있다. 예: Axiom 상의 Uniswap TWAP 오라클
-
옵션 가격 산정: 체인상 옵션 프로토콜은 자산이 지난 n개의 블록 동안 탈중앙화 거래소에서 보인 변동성을 기반으로 옵션 가격을 책정할 수 있다.
마지막 두 가지 사례는 소스 체인에 새 블록이 추가될 때 증명을 업데이트해야 한다.
미들웨어:
-
의도(Intent): 저장 증명은 사용자가 의도를 더 표현력 있고 명확하게 설정할 수 있게 한다. 해결사(solver)의 역할은 사용자의 의도를 충족시키기 위한 필수 단계를 수행하는 것이지만, 사용자는 체인상 데이터와 매개변수를 기반으로 조건을 더 명확히 지정할 수 있다. 해결사는 최적 솔루션을 찾기 위해 활용한 체인상 데이터의 유효성을 입증할 수도 있다.
-
계정 추상화(Account Abstraction): 사용자는 다른 체인의 데이터를 기반으로 규칙을 설정할 수 있다. 예를 들어, 모든 지갑에는 nonce가 있다. 1년 전 nonce가 특정 숫자였고 현재도 동일하다는 것을 증명할 수 있다. 이를 통해 해당 지갑이 전혀 사용되지 않았음을 입증하고, 지갑 접근 권한을 다른 지갑에 위임할 수 있다.
-
체인상 자동화: 스마트 계약은 체인상 데이터에 의존하는 사전 정의된 조건에 따라 특정 작업을 자동으로 수행할 수 있다. 자동화 프로그램은 AMM의 최적 가격 흐름을 유지하거나 불량 채무를 방지해 대출 프로토콜의 건강성을 유지하기 위해 정기적으로 스마트 계약을 호출해야 한다. HyperOracle은 자동화와 체인상 데이터 접근을 모두 지원한다.
인프라
-
신뢰
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News














