밸리디움
밸리디움은 ZK-롤업과 같이 유효성 증명을 사용하여 트랜잭션의 무결성을 강제하지만, 트랜잭션 데이터를 이더리움 메인넷에 저장하지 않는 확장성 솔루션입니다. 오프체인 데이터 가용성은 트레이드오프를 수반하지만, 확장성을 크게 향상시킬 수 있습니다(밸리디움은 초당 약 9,000건 이상의 트랜잭션 (opens in a new tab)을 처리할 수 있습니다).
전제 조건
이더리움 확장성 및 레이어 2 (l2)에 대한 페이지를 읽고 이해해야 합니다.
밸리디움이란 무엇인가요?
밸리디움은 이더리움 메인넷 외부에서 트랜잭션을 처리하여 처리량을 향상시키도록 설계된 오프체인 데이터 가용성 및 연산을 사용하는 확장성 솔루션입니다. 영지식 롤업(ZK-롤업)과 마찬가지로, 밸리디움은 이더리움에서 오프체인 트랜잭션을 검증하기 위해 을 게시합니다. 이는 유효하지 않은 상태 전환을 방지하고 밸리디움 체인의 보안 보장을 강화합니다.
이러한 "유효성 증명"은 ZK-SNARKs(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) 또는 ZK-STARKs(Zero-Knowledge Scalable Transparent ARgument of Knowledge)의 형태로 제공될 수 있습니다. 영지식 증명 (opens in a new tab)에 대해 자세히 알아보기.
밸리디움 사용자의 자금은 이더리움의 스마트 컨트랙트에 의해 제어됩니다. 밸리디움은 ZK-롤업과 마찬가지로 거의 즉각적인 인출을 제공합니다. 인출 요청에 대한 유효성 증명이 메인넷에서 검증되면, 사용자는 머클 증명을 제공하여 자금을 인출할 수 있습니다. 머클 증명은 검증된 트랜잭션 배치에 사용자의 인출 트랜잭션이 포함되어 있음을 검증하여, 온체인 컨트랙트가 인출을 처리할 수 있도록 합니다.
그러나 밸리디움 사용자는 자금이 동결되고 인출이 제한될 수 있습니다. 이는 밸리디움 체인의 데이터 가용성 관리자가 사용자에게 오프체인 상태 데이터를 제공하지 않을 때 발생할 수 있습니다. 트랜잭션 데이터에 접근할 수 없으면, 사용자는 자금의 소유권을 증명하고 인출을 실행하는 데 필요한 머클 증명을 계산할 수 없습니다.
이것이 밸리디움과 ZK-롤업의 주요 차이점이며, 데이터 가용성 스펙트럼에서의 위치가 다릅니다. 두 솔루션 모두 데이터 저장에 다르게 접근하며, 이는 보안 및 무신뢰성에 영향을 미칩니다.
밸리디움은 이더리움과 어떻게 상호작용하나요?
밸리디움은 기존 이더리움 체인 위에 구축된 확장성 프로토콜입니다. 트랜잭션을 오프체인에서 실행하지만, 밸리디움 체인은 메인넷에 배포된 다음과 같은 스마트 컨트랙트 모음에 의해 관리됩니다.
-
검증자 컨트랙트: 검증자 컨트랙트는 상태 업데이트를 수행할 때 밸리디움 운영자가 제출한 증명의 유효성을 검증합니다. 여기에는 오프체인 트랜잭션의 정확성을 증명하는 유효성 증명과 오프체인 트랜잭션 데이터의 존재를 검증하는 데이터 가용성 증명이 포함됩니다.
-
메인 컨트랙트: 메인 컨트랙트는 블록 생성자가 제출한 상태 커밋먼트(머클 루트)를 저장하고, 유효성 증명이 온체인에서 검증되면 밸리디움의 상태를 업데이트합니다. 이 컨트랙트는 또한 밸리디움 체인으로의 입금 및 인출을 처리합니다.
밸리디움은 또한 다음 사항에 대해 메인 이더리움 체인에 의존합니다.
정산
밸리디움에서 실행된 트랜잭션은 부모 체인이 그 유효성을 검증할 때까지 완전히 확정될 수 없습니다. 밸리디움에서 수행되는 모든 작업은 결국 메인넷에서 정산되어야 합니다. 이더리움 블록체인은 또한 밸리디움 사용자에게 "정산 보장"을 제공합니다. 즉, 오프체인 트랜잭션이 온체인에 커밋되면 되돌리거나 변경할 수 없습니다.
보안
정산 레이어 역할을 하는 이더리움은 밸리디움의 상태 전환 유효성도 보장합니다. 밸리디움 체인에서 실행된 오프체인 트랜잭션은 기본 이더리움 레이어의 스마트 컨트랙트를 통해 검증됩니다.
온체인 검증자 컨트랙트가 증명을 유효하지 않다고 판단하면 트랜잭션은 거부됩니다. 이는 운영자가 밸리디움의 상태를 업데이트하기 전에 이더리움 프로토콜이 강제하는 유효성 조건을 충족해야 함을 의미합니다.
밸리디움은 어떻게 작동하나요?
트랜잭션
사용자는 밸리디움 체인에서 트랜잭션을 실행하는 역할을 하는 노드인 운영자에게 트랜잭션을 제출합니다. 일부 밸리디움은 체인을 실행하기 위해 단일 운영자를 사용하거나 운영자를 교체하기 위해 지분 증명 (PoS) 메커니즘에 의존할 수 있습니다.
운영자는 트랜잭션을 배치로 집계하고 증명을 위해 증명 회로로 보냅니다. 증명 회로는 트랜잭션 배치(및 기타 관련 데이터)를 입력으로 받아 작업이 올바르게 수행되었음을 검증하는 유효성 증명을 출력합니다.
상태 커밋먼트
밸리디움의 상태는 머클 트리로 해시되며, 그 루트는 이더리움의 메인 컨트랙트에 저장됩니다. 상태 루트라고도 하는 머클 루트는 밸리디움의 계정 및 잔액의 현재 상태에 대한 암호화 커밋먼트 역할을 합니다.
상태 업데이트를 수행하려면 운영자는 (트랜잭션 실행 후) 새로운 상태 루트를 계산하여 온체인 컨트랙트에 제출해야 합니다. 유효성 증명이 확인되면 제안된 상태가 수락되고 밸리디움은 새로운 상태 루트로 전환됩니다.
입금 및 인출
사용자는 온체인 컨트랙트에 ETH(또는 ERC 호환 토큰)를 입금하여 이더리움에서 밸리디움으로 자금을 이동합니다. 컨트랙트는 입금 이벤트를 오프체인 밸리디움으로 중계하고, 여기서 사용자의 주소에 입금액과 동일한 금액이 적립됩니다. 운영자는 또한 이 입금 트랜잭션을 새로운 배치에 포함시킵니다.
자금을 메인넷으로 다시 이동하려면, 밸리디움 사용자는 인출 트랜잭션을 시작하고 이를 운영자에게 제출합니다. 운영자는 인출 요청을 검증하고 배치에 포함시킵니다. 밸리디움 체인에 있는 사용자의 자산은 시스템을 종료하기 전에 파기됩니다. 배치와 관련된 유효성 증명이 검증되면, 사용자는 메인 컨트랙트를 호출하여 초기 입금액의 잔액을 인출할 수 있습니다.
검열 방지 메커니즘으로서, 밸리디움 프로토콜은 사용자가 운영자를 거치지 않고 밸리디움 컨트랙트에서 직접 인출할 수 있도록 허용합니다. 이 경우 사용자는 계정이 상태 루트에 포함되어 있음을 보여주는 머클 증명을 검증자 컨트랙트에 제공해야 합니다. 증명이 수락되면 사용자는 메인 컨트랙트의 인출 함수를 호출하여 밸리디움에서 자금을 종료할 수 있습니다.
배치 제출
트랜잭션 배치를 실행한 후, 운영자는 관련 유효성 증명을 검증자 컨트랙트에 제출하고 메인 컨트랙트에 새로운 상태 루트를 제안합니다. 증명이 유효하면 메인 컨트랙트는 밸리디움의 상태를 업데이트하고 배치 내 트랜잭션 결과를 완결합니다.
ZK-롤업과 달리, 밸리디움의 블록 생성자는 트랜잭션 배치에 대한 트랜잭션 데이터를 게시할 필요가 없습니다(블록 헤더만 게시). 이로 인해 밸리디움은 블롭 데이터, calldata 또는 이 둘의 조합을 사용하여 메인 이더리움 체인에 상태 데이터를 게시하는 "하이브리드" 확장성 프로토콜(예: 레이어 2 (l2))과 달리 순수한 오프체인 확장성 프로토콜이 됩니다.
데이터 가용성
앞서 언급했듯이, 밸리디움은 운영자가 모든 트랜잭션 데이터를 이더리움 메인넷 외부에 저장하는 오프체인 데이터 가용성 모델을 활용합니다. 밸리디움의 낮은 온체인 데이터 공간 차지는 확장성을 향상시키고(처리량이 이더리움의 데이터 처리 용량에 의해 제한되지 않음) 사용자 수수료를 줄입니다(온체인에 데이터를 게시하는 비용이 더 낮음).
그러나 오프체인 데이터 가용성은 문제를 야기합니다. 머클 증명을 생성하거나 검증하는 데 필요한 데이터를 사용할 수 없을 수 있습니다. 이는 운영자가 악의적으로 행동할 경우 사용자가 온체인 컨트랙트에서 자금을 인출하지 못할 수 있음을 의미합니다.
다양한 밸리디움 솔루션은 상태 데이터의 저장을 탈중앙화하여 이 문제를 해결하려고 시도합니다. 여기에는 블록 생성자가 오프체인 데이터를 저장하고 요청 시 사용자에게 제공할 책임이 있는 "데이터 가용성 관리자"에게 기본 데이터를 보내도록 강제하는 것이 포함됩니다.
밸리디움의 데이터 가용성 관리자는 모든 밸리디움 배치에 서명하기를 통해 오프체인 트랜잭션에 대한 데이터 가용성을 증명합니다. 이러한 서명은 온체인 검증자 컨트랙트가 상태 업데이트를 승인하기 전에 확인하는 "가용성 증명"의 한 형태를 구성합니다.
밸리디움은 데이터 가용성 관리에 대한 접근 방식이 다릅니다. 일부는 상태 데이터를 저장하기 위해 신뢰할 수 있는 당사자에 의존하는 반면, 다른 일부는 이 작업에 무작위로 할당된 검증자를 사용합니다.
데이터 가용성 위원회(DAC)
오프체인 데이터의 가용성을 보장하기 위해 일부 밸리디움 솔루션은 상태의 복사본을 저장하고 데이터 가용성 증명을 제공하기 위해 데이터 가용성 위원회(DAC)로 통칭되는 신뢰할 수 있는 엔티티 그룹을 임명합니다. DAC는 멤버 수가 적기 때문에 구현하기 쉽고 조정이 덜 필요합니다.
그러나 사용자는 필요할 때(예: 머클 증명 생성 시) 데이터를 사용할 수 있도록 DAC를 신뢰해야 합니다. 데이터 가용성 위원회의 구성원이 악의적인 행위자에게 손상되어 (opens in a new tab) 오프체인 데이터를 제공하지 않을 가능성이 있습니다.
밸리디움의 데이터 가용성 위원회에 대해 자세히 알아보기 (opens in a new tab).
보증된 데이터 가용성
다른 밸리디움은 오프라인 데이터를 저장하는 역할을 맡은 참가자가 역할을 수행하기 전에 스마트 컨트랙트에 토큰을 스테이크(즉, 락업)하도록 요구합니다. 이 스테이크는 데이터 가용성 관리자 간의 정직한 행동을 보장하는 "보증금" 역할을 하며 신뢰 가정을 줄입니다. 이러한 참가자가 데이터 가용성을 증명하지 못하면 보증금은 슬래싱됩니다.
보증된 데이터 가용성 체계에서는 필요한 스테이크를 제공하면 누구나 오프체인 데이터를 보관하도록 할당될 수 있습니다. 이는 적격한 데이터 가용성 관리자 풀을 확장하여 데이터 가용성 위원회(DAC)에 영향을 미치는 중앙화를 줄입니다. 더 중요한 것은, 이 접근 방식이 악의적인 활동을 방지하기 위해 암호경제적 인센티브에 의존한다는 점이며, 이는 밸리디움에서 오프라인 데이터를 보호하기 위해 신뢰할 수 있는 당사자를 임명하는 것보다 훨씬 더 안전합니다.
밸리디움의 보증된 데이터 가용성에 대해 자세히 알아보기 (opens in a new tab).
볼리션과 밸리디움
밸리디움은 많은 이점을 제공하지만 트레이드오프(가장 눈에 띄는 것은 데이터 가용성)가 따릅니다. 그러나 많은 확장성 솔루션과 마찬가지로 밸리디움은 특정 사용 사례에 적합하며, 이것이 볼리션(Volition)이 만들어진 이유입니다.
볼리션은 ZK-롤업과 밸리디움 체인을 결합하여 사용자가 두 확장성 솔루션 간에 전환할 수 있도록 합니다. 볼리션을 사용하면 사용자는 특정 트랜잭션에 대해 밸리디움의 오프체인 데이터 가용성을 활용하는 동시에, 필요한 경우 온체인 데이터 가용성 솔루션(ZK-롤업)으로 전환할 수 있는 자유를 유지할 수 있습니다. 이는 본질적으로 사용자에게 고유한 상황에 따라 트레이드오프를 선택할 수 있는 자유를 제공합니다.
탈중앙화 거래소(DEX)는 고가치 거래를 위해 밸리디움의 확장 가능하고 프라이버시가 보장되는 인프라를 사용하는 것을 선호할 수 있습니다. 또한 ZK-롤업의 더 높은 보안 보장과 무신뢰성을 원하는 사용자를 위해 ZK-롤업을 사용할 수도 있습니다.
밸리디움과 EVM 호환성
ZK-롤업과 마찬가지로 밸리디움은 토큰 스왑 및 결제와 같은 간단한 애플리케이션에 주로 적합합니다. 영지식 증명 회로에서 EVM 명령어를 증명하는 데 상당한 오버헤드가 발생한다는 점을 고려할 때, 밸리디움 간에 일반적인 연산 및 스마트 컨트랙트 실행을 지원하는 것은 구현하기 어렵습니다.
일부 밸리디움 프로젝트는 EVM 호환 언어(예: Solidity, Vyper)를 컴파일링하여 효율적인 증명에 최적화된 맞춤형 바이트코드를 생성함으로써 이 문제를 회피하려고 시도합니다. 이 접근 방식의 단점은 새로운 영지식 증명 친화적인 VM이 중요한 EVM 연산 코드를 지원하지 않을 수 있으며, 개발자가 최적의 경험을 위해 고급 언어로 직접 작성해야 한다는 것입니다. 이는 더 많은 문제를 야기합니다. 개발자가 완전히 새로운 개발 스택으로 탈중앙화 애플리케이션 (dapp)을 구축하도록 강제하고 현재 이더리움 인프라와의 호환성을 깨뜨립니다.
그러나 일부 팀은 ZK 증명 회로를 위해 기존 EVM 연산 코드를 최적화하려고 시도하고 있습니다. 이로 인해 프로그램 실행의 정확성을 검증하기 위한 증명을 생성하는 EVM 호환 VM인 영지식 이더리움 가상 머신(zkEVM)이 개발될 것입니다. zkEVM을 사용하면 밸리디움 체인은 오프체인에서 스마트 컨트랙트를 실행하고 유효성 증명을 제출하여 이더리움에서 (다시 실행할 필요 없이) 오프체인 연산을 검증할 수 있습니다.
zkEVM에 대해 자세히 알아보기 (opens in a new tab).
밸리디움은 이더리움을 어떻게 확장하나요?
1. 오프체인 데이터 저장
옵티미스틱 롤업 및 ZK-롤업과 같은 레이어 2 (l2) 확장성 프로젝트는 L1에 일부 트랜잭션 데이터를 게시하여 보안을 위해 순수 오프체인 확장성 프로토콜(예: 플라즈마)의 무한한 확장성을 포기합니다. 그러나 이는 롤업의 확장성 속성이 이더리움 메인넷의 데이터 대역폭에 의해 제한됨을 의미합니다(이러한 이유로 데이터 샤딩은 이더리움의 데이터 저장 용량을 개선할 것을 제안합니다).
밸리디움은 모든 트랜잭션 데이터를 오프체인에 유지하고 메인 이더리움 체인에 상태 업데이트를 중계할 때 상태 커밋먼트(및 유효성 증명)만 게시함으로써 확장성을 달성합니다. 그러나 유효성 증명의 존재는 밸리디움에 플라즈마 및 사이드체인을 포함한 다른 순수 오프체인 확장성 솔루션보다 더 높은 보안 보장을 제공합니다. 오프체인 트랜잭션을 검증하기 전에 이더리움이 처리해야 하는 데이터의 양을 줄임으로써 밸리디움 설계는 메인넷의 처리량을 크게 확장합니다.
2. 재귀적 증명
재귀적 증명은 다른 증명의 유효성을 검증하는 유효성 증명입니다. 이러한 "증명의 증명"은 이전의 모든 증명을 검증하는 하나의 최종 증명이 생성될 때까지 여러 증명을 재귀적으로 집계하여 생성됩니다. 재귀적 증명은 유효성 증명당 검증할 수 있는 트랜잭션 수를 늘려 블록체인 처리 속도를 확장합니다.
일반적으로 밸리디움 운영자가 검증을 위해 이더리움에 제출하는 각 유효성 증명은 단일 블록의 무결성을 검증합니다. 반면 단일 재귀적 증명은 여러 밸리디움 블록의 유효성을 동시에 확인하는 데 사용할 수 있습니다. 이는 증명 회로가 여러 블록 증명을 하나의 최종 증명으로 재귀적으로 집계할 수 있기 때문에 가능합니다. 온체인 검증자 컨트랙트가 재귀적 증명을 수락하면 모든 기본 블록이 즉시 완결됩니다.
밸리디움의 장단점
| 장점 | 단점 |
|---|---|
| 유효성 증명은 오프체인 트랜잭션의 무결성을 강제하고 운영자가 유효하지 않은 상태 업데이트를 완결하는 것을 방지합니다. | 유효성 증명을 생성하려면 특수 하드웨어가 필요하며, 이는 중앙화 위험을 초래합니다. |
| 사용자의 자본 효율성 증가(이더리움으로 자금을 인출하는 데 지연이 없음) | 일반 연산/스마트 컨트랙트에 대한 지원이 제한적이며, 개발을 위해 특수 언어가 필요합니다. |
| 고가치 애플리케이션에서 사기 증명 기반 시스템이 직면하는 특정 경제적 공격에 취약하지 않습니다. | ZK 증명을 생성하는 데 높은 컴퓨팅 파워가 필요하며, 처리량이 낮은 애플리케이션에는 비용 효율적이지 않습니다. |
| 이더리움 메인넷에 콜 데이터를 게시하지 않음으로써 사용자의 가스 수수료를 줄입니다. | 주관적 완결성 시간은 더 느리지만(ZK 증명 생성에 10-30분 소요), 분쟁 시간 지연이 없기 때문에 완전한 완결성에는 더 빠릅니다. |
| 트랜잭션 프라이버시 및 확장성을 우선시하는 거래 또는 블록체인 게임과 같은 특정 사용 사례에 적합합니다. | 소유권의 머클 증명을 생성하려면 오프체인 데이터를 항상 사용할 수 있어야 하므로 사용자가 자금을 인출하지 못할 수 있습니다. |
| 오프체인 데이터 가용성은 더 높은 수준의 처리량을 제공하고 확장성을 증가시킵니다. | 순수하게 암호화 보안 메커니즘에 의존하는 ZK-롤업과 달리, 보안 모델은 신뢰 가정 및 암호경제적 인센티브에 의존합니다. |
밸리디움/볼리션 사용하기
여러 프로젝트에서 탈중앙화 애플리케이션 (dapp)에 통합할 수 있는 밸리디움 및 볼리션 구현을 제공합니다.
StarkWare StarkEx - StarkEx는 유효성 증명을 기반으로 하는 이더리움 레이어 2 (l2) 확장성 솔루션입니다. ZK-롤업 또는 밸리디움 데이터 가용성 모드 중 하나로 작동할 수 있습니다.
Matter Labs zkPorter- zkPorter는 zkRollup과 샤딩의 아이디어를 결합한 하이브리드 접근 방식으로 데이터 가용성 문제를 해결하는 레이어 2 (l2) 확장성 프로토콜입니다. 각각 고유한 데이터 가용성 정책을 가진 임의의 많은 샤드를 지원할 수 있습니다.