이더리움 L2 네트워크의 운영 안정성
이더리움 Layer 2 블록 증명 방식
이더리움 Layer 2 네트워크는 각 목적에 따라 Optimistic, Validity 등의 블록 검증 방식을 이용한다.
이전에 소개한 zkSync Era는 Validity 검증 방식 중 boojum 이라는 증명 알고리즘을 이용하는 예시다.
이 글에서는 Layer 2 네트워크의 블록 증명 방식에 따른 운영 안정성을 고려하기 위한 내용을 다룬다.
Optimistic
Optimistic 검증 방식은 낙관적 블록 생성방식이다.
블록에 오류가 없을 것으로 추정하고, Layer 1으로 블록을 제출하여 약 7일간의 이의제기 기간을 대기한 후 블록을 확정하는 방식이다.
이 방식은 별도의 블록 검증 없이 바로 Layer 1으로 제출하기에 네트워크 처리 연산량이 적다는 장점이 있지만, 블록 오류가 있는 경우 치명적인 네트워크 혼란이 생길 수 있다.
블록 오류가 이의제기 기간 내에 발견되면 Optimistic 네트워크는 오류 블록의 등록을 취소하고, 해당 블록 기록자에 대한 페널티를 부여하는 방식으로 네트워크 신뢰를 확보한다.
오류 블록이 취소됨으로 인해서 해당 블록이 포함하는 트랜잭션 작업이 무효가 되는 것은 아니다.
초기 방식에서는 문제를 발견한 블록에 대해서 큰 비용이 필요하지만 신뢰도를 보장하는 Layer 1에서 다시 블록 내부 작업을 수행 후 정정된 블록을 기록하는 방식으로 오류를 해결했다.
최근에는 문제 블록 내부에서 오류의 원인이 되는 트랜잭션을 찾은 뒤 최소 실행 단위만 Layer 1에서 다시 실행 후 블록을 정정하는 방식도 이용되고 있다.
Optimistic의 이의제기 기간 방식으로 인해 DeFi 서비스 또는 실시간 확정이 필요한 서비스는 불편을 겪을 수 있다.
DeFi 서비스의 경우는 자금 인출이 블록 확정까지 지연되는 점, 실시간 확정이 필요한 서비스는 트랜잭션 실행 결과에 대한 신뢰를 보장할 수 없는 점이다.
BoLD
악의적인 이의제기로 인해 블록 확정이 무한정 지연되는 문제를 해결하기 위해 검증자 중 올바른 검증을 제출하는 1건의 경우를 이용해서 다른 이의제기를 무효화하는 Optimistic 세부 알고리즘이다.
OPFP
내부적인 이더리움 가상 머신(EVM)을 이용한 검증 방식이다. 오류 발생 시 Layer 1에서 실행한 EVM을 이용해 블록을 다시 연산하고, 정정한다.
OP Kailua
블록의 오류 발생 시에만 영지식 증명(ZK)를 이용해 정정하는 방식이다. Optimistic의 빠른 Layer 1 제출의 강점을 이용하고, 블록 확정 지연시간을 줄이기 위해 ZK로 블록을 검증한다.
Validity
Validity 방식은 각 블록에 대해 Layer 2에서 검증 후 Layer 1으로 제출하는 방식이다.
Layer 2 네트워크 내부에서 블록 검증 연산이 실행되기 때문에 네트워크 부담 연산량이 늘어나고, 검증 연산 후 Layer 1으로 블록이 제출되기 때문에 블록의 미확정 시간이 검증 대기열 상태에 따라 변동되는 점이 특징이다.
블록 검증을 위해 영지식 증명(ZK)를 이용해 각 작업 단위를 검증하는 것이 기본 방식이다.
ZK는 연산 방식에 따라 SNARK, STARK로 구분된다.
현재 이더리움 메인넷이 채택한 ZK 는 SNARK 방식이지만, 일부 Layer 2는 메인넷과 별개로 STARK를 채택하여 검증하는 경우도 있다.(대표적인 Layer 2 starknet)
최근 구글의 양자컴퓨터 연구로 확산된 양자내성증명 방식은 STARK 방식이다.
STARK 방식과 SNARK 방식은 기본 알고리즘의 채택이 완전히 달라 서로 다른 특성을 가진다.
SNARK 방식은 각 데이터를 타원곡선 암호를 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘에 취약한 타원곡선 암호로 인해 양자 위협에 노출된다.
STARK 방식은 각 데이터를 해시 변환을 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘이 역산하기에 어려운 방식을 이용하여 양자 내성을 가지지만 해시 데이터의 크기로 인해 증명 데이터 용량이 SNARK에 비해 매우 커서 네트워크 연산 부담이 크다.
Stwo
STARK 방식의 증명을 경량화해 네트워크 부담을 낮추는 방식의 증명 방식이다.
Linea
격자기반 암호를 이용하는 증명 방식이다.
Boojum
STARK 방식의 고성능 증명 방식이다.
OpenVM
별도의 지정 증명 방식 없이 연산 도구만 제공하는 방식이다.
채택 네트워크가 별도로 증명 알고리즘을 지정한다.
전용 RPC 노드
이더리움 Layer 2의 사용으로 블록 생성 부담이 줄어 네트워크 가용성이 확보되었지만, 사용자의 체감 가용성은 트랜잭션을 처리하는 RPC 노드의 최대 처리 속도 제한으로 개선이 필수적이다.
높은 처리 속도와 낮은 지연 시간을 요구하는 경우, 트랜잭션 처리 중 노드 오류를 최소화하기 위해 전용 RPC 노드를 사용한다.
RPC 노드는 네트워크를 구성하는 각 노드를 의미하며, 사용자는 임의의 RPC 노드에 트랜잭션을 제출하며 RPC 노드가 로컬에서 트랜잭션 오류 확인 후 다른 노드와 공유하여 저장하는 방식으로 네트워크에 트랜잭션 결과가 저장된다.
전용 RPC 노드는 특정 목적을 위해 RPC 노드를 인증된 사용자만 이용할 수 있도록 제공하는 방식이다.
일반적인 RPC 노드는 다수의 사용자가 제출하는 트랜잭션 처리를 위해 최대 처리 속도가 낮게 설정되는 반면, 전용 RPC 노드는 인증된 소수의 사용자가 제출하는 트랜잭션만 처리하기에 높은 처리 속도를 가진다.
또한, 전용 RPC 노드는 노드 오류로 인한 트랜잭션 지연을 보상하는 구조가 설계되어 있어 기업 서비스에서 트랜잭션 처리 신뢰도를 높이기 위한 수단으로 이용된다.
Web3 서비스를 위한 고려사항
Layer 2로의 네트워크 확장으로 다양한 RPC 노드가 필요해졌다.
그 이유는 각 네트워크의 블록 생성 방식의 다름으로 네트워크 특화 노드가 필요하고, 블록 증명이 Layer 2 네트워크에서 수행되는 경우 노드의 연산 부하가 블록 생성 속도에 비례해 늘어나기 때문에 연산 능력의 향상이 요구되기 때문이다.
따라서 안정적인 Web3 서비스 운영과 블록 신뢰도를 위해 Validity 방식의 블록 생성 네트워크를 채택하며, 양자내성 네트워크를 고려하는 경우를 고려하면 전용 RPC 노드를 적극 활용해야 한다.
사용 목적에 따른 블록 생성 방식을 제안한다.
| 사용 목적 | 블록 생성 방식 | 특징 |
|---|---|---|
| 실시간 반응형(게임, 소셜 네트워크) | Optimistic | 빠른 Layer 2 기록으로 데이터 송수신 속도 최적화 |
| 데이터 검증형(전자계약, 자산 송금) | Validity | Layer 2에서의 블록 검증을 통한 빠른 블록 확정, 서비스 신뢰를 ZK 증명 방식의 무결성으로 확장 |
서비스에 사용할 네트워크 선정 시 참고할 수 있는 사이트를 아래에 기재한다.
L2Beat