[암호경제적 보안 시리즈] — 2. Shared Security
Author: woogieboogie.jl, sangsang
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By (하성환, 박찬우, 임요한)
[암호경제적 보안 시리즈] — 1. Crypto Economic Security & Liquid Staking
[암호경제적 보안 시리즈] — 2. Shared Security
자산의 불안정성에서 기인하는 보안 공유 시장의 형성
앞서 암호경제적 보안개념과 이를 확장시키는 방법 중 하나인 유동 스테이킹에 대해 알아보면서, 단일 체인에서 PoS와 같은 프로토콜 레벨에서의 합의 알고리즘, 그리고 애플리케이션 레벨에서의 유동스테이킹과 같은 방법을 통해 악의적 공격에 효과적으로 방어할 수 있음을 알게 되었다. 허나 문제는 새롭게 체인을 런칭하는 경우로, 적은 시가총액 및 크나큰 변동성은 블록체인의 암호경제적 보안을 유지하는데 여전히 걸림돌로 작용한다.
예를 들어보자, 재단이 새로운 프로젝트를 코스모스 앱체인의 형태로 출시했다면, 발행한 프로젝트의 스테이킹 자산은 변동성이 너무 심하고, 그 규모가 크지 않아, 체인의 보안성을 확신할 수 없는 딜레마에 빠지기 쉽다.
결국 안정적인 실행환경 보장의 목적으로 직접 밸리데이터를 운영하는 것 보다 더 저렴한 비용으로 기존 안정화된 체인의 암호경제적 보안을 공유받고자 하는 수요가 발생하게 되며, 여기서 보안 공유 시장에 대한 니즈가 발생한다.
보안을 공유하는 세가지 방법
이렇게 보안을 공유하는 방법엔 크게 세가지가 있다, 바로 1)롤업, 2)리스테이킹, 그리고 3)네이티브 보안 공유 방식이다. 물론 이 외에도 타 체인의 블록 타임마다 체크포인트를 생성하거나(바빌론 체인, Babylon Chain 등)이나 트랜잭션의 메모란을 이용하여 완결성을 확보하는 등(스택스, Proof of Transaction) 다양한 방법이 존재할 수 있으나, 본 글에서는 주요 보안 공유 방식이라고 평가받는 위 세가지 방식에 대해 다뤄보고자 하며, 각 방식별 보안의 공유 방법을 간단히 설명하면 아래와 같다.
I. 롤업 (Rollups)
- 롤업은 이더리움과 같은 메인넷 위에서 작동하는 레이어 2 확장성 솔루션이다. 여러 트랜잭션을 레이어2라는 오프체인 환경에서 실행한 후 이것의정합성을 가진 일종의 증명을 레이어 1에 제출하며, 레이어1에서 해당 증명이 받아들여지는 과정에서 롤업은 기반 블록체인의 보안을 상속받게 된다.
II. 리스테이킹 (Restaking)
- 리스테이킹이란 EigenLayer라는 프로젝트에서 처음 제시한 개념으로, 유동 스테이킹 프로토콜이나, 직접 이더리움의 합의 레이어에 스테이킹한 이더리움을 EigenLayer의 스마트 컨트랙트 등을 통하여 예치하는 리스테이킹(Restaking)이라는 행위를 통해 기반 블록체인의 암호경제학적 보안 타 체인이나 미들웨어로 공유하게 된다.
III. 네이티브 보안 공유 (Native Shared-Security)
- 네이티브 보안 공유는 공통된 컨센서스 매커니즘이나 실행환경을 기반으로 체인에 내장된 특정 프로토콜을 기반으로 타 체인에 보안을 공유하는 방식을 말한다. 여기서는 최근 도입이 결정된 코스모스(Cosmos)의 ICS(InterChain-Security)와 폴카닷(Polkadot)의 파라체인 프로토콜을 통한 보안 공유 방식에 대해 알아보도록 하겠다.
1. 보안을 공유하는 방법 1 — 롤업
롤업은 효율적인 실행환경을 오프체인에서 구축하고 이를 콜데이터 형태로 이더리움에 저장하는 방식으로 이더리움의 보안을 레버리징하는 확장 솔루션을 지칭한다. 데이터의 검증하는 방식에 따라 사기증명(Fraud Proof)과 유효성 증명(Validity Proof) 나뉘며, 이 분류에 따라 옵티미스틱 롤업과 ZK 롤업으로 구분된다. 본 글에서는 이들의 작동 방식에 대한 이야기는 차치하고, 유효성을 검증하는 방식에 따라 레이어 1의 보안이 어떻게 상속되는지를 집중적으로 살펴보려 한다. (자세한 작동 방식에 대해서는 다음 글들을 추천한다: 디사이퍼, a41)
롤업의 구성 요소는 공통적으로 시퀀서*, 오퍼레이터**, 밸리데이터***(추가적인 검증을 레이어 2단에서 진행할 경우), 그리고 영지식 롤업의 경우 레이어 2에서 실행된 내역에 대한 증명을 만들어주는 증명자와 증명자가 생성한 데이터를 검증하는 레이어 1의 검증인 컨트랙트가 추가로 구성된다. 이어서 각 롤업 방식별로 실행된 트랜잭션이 이더리움에 어떻게 완결성을 기록하는지 트랜잭션의 흐름을 따라가며 알아보도록 하자.
*시퀀서(Sequencer): 시퀀서는 롤업 블록에서 트랜잭션을 정렬하기 위한 요소로, 트랜잭션의 순서를 정해 블록을 구성하는 역할을 맡는다.
**오퍼레이터(Operator): 옵티미스틱 롤업에서 오퍼레이터는 시퀀서가 전달한 블록을 받고, 이것의 트랜잭션 머클 트리를 만든다. 이후 해당 머클트리의 머클루트를 이더리움 메인 체인에 콜데이터 형태로 저장한다.
***검증인(Validator): 롤업단에서 사전 검증이 필요할 경우 필요한 요소로, 레이어 2에서 올바른 트랜잭션이 실행되어있는지 검증하는 역할을 진행한다.
1-a. 옵티미스틱 롤업에서의 보안 공유: 챌린지와 사기증명
옵티미스틱 롤업은 이더리움의 보안을 공유받는 방법으로 레이어 1으로 제출된 모든 트랜잭션을 믿는 것을 그 대전제로 한다. 다만 틀린 트랜잭션이 있을 경우를 대비해 대략적으로 7일간의 챌린지 기간이 존재하며, 챌린지가 제출되면 제출된 시점과 체크포인트 이후 시점부터 모든 트랜잭션을 재실행해보면서** 정합성을 재확인하며, 진실되지 못한 오퍼레이터(해당 블록을 이더리움 L1에 기록하는 역할)는 슬래싱 당하고 롤업 체인의 블록은 그 시점을 기점으로 롤백(reverted) 된다.
이제 실제 롤업에서 발생하는 트랜잭션의 흐름을 통해 롤업에서 발생한 실행(execution)내역이 어떻게 레이어 1에서 완결성을 갖게 되는지 아래와 같이 알아보도록 하겠다.
- Optimistic Rollup은 온체인 데이터(콜데이터)와 오프체인 계산의 조합을 사용한다. 거래들은 “오퍼레이터” 또는 “시퀀서”라고 불리는 엔티티에 의해 묶여 오프체인에서 실행되며, 시퀀서는 거래를 정렬하고 “롤업 블록”으로 묶인다. 거래를 실행한 후, 시퀀서는 오프체인 거래의 결과 상태를 나타내는 상태 루트를 생성하고 이를 이더리움 블록체인에 제출하게 된다.
- 이 스테이트 루트 제출은 일종의”제안”으로 간주되며, 제출된 후 7일간의 챌린지 기간을 가지게 된다. 이 기간 동안, 어떤 사용자라도 제안된 스테이트 루트의 정확성에 이의를 제기할 수 있다. 만약 이의 제기가 성공적이라면, 블록 제안자의 보증금(담보)는 몰수되고, 롤업은 이전의 올바른 상태로 되돌아가게 된다. 만약 제안 없이 7일이 지나 트랜잭션에 대한 체크포인트가 이더리움에 기록되면 해당 트랜잭션은 이더리움에서 완결성을 가지게 된다.
*콜데이터와 가스비용: 콜데이터는 이더리움에 트랜잭션의 입력값을 저장하기 위해 사용되는 메모리 타입으로, 읽기만 지원되는 메모리로 이더리움 내 가스 소모량은 바이트당 16가스로 지정되어 있다. 이는 일반 이더리움 트랜잭션 발생 비용보다 현저히 낮은 수치로 롤업과 같은 확장성 솔루션에서 데이터의 완결성을 보장하는데 쓰이고 있다.
**프로토콜마다 재실행 및 챌린지에 대한 검증 방식이 다르다. 아비트럼은 일부 트랜잭션에 대해서만 재실행, 옵티미즘은 체크포인트 이후 모든 트랜잭션에 대해 재실행을 하여 챌린지에 대한 검증을 진행한다.
1–b. ZK 롤업에서의 보안 공유: 증명자와 검증자
반면 ZK 롤업은 모든 트랜잭션의 검증이 이뤄진 후 L1에 기록되는 방식으로, 이를 위해 레이어 2엔 트랜잭션의 정합성에 대한 영지식 증명을 기록할 증명자(Prover)와 레이어 1(메인 체인)엔 생성된 증명을 검증하는 검증자(Verifier)가 추가된다.
이를 기반으로 L2에서 발생한 트랜잭션에 어떻게 이더리움에서 완결성을 가지게 되는지 알아보자. 레이어 1의 검증자 컨트랙트는 증명과 롤업 트랜잭션의 스테이트 루트를 받아 증명에 대한 검증이 끝나면 레이어 1의 State를 업데이트 하거나 이를 따로 기록하는 레지스트리 컨트랙트(L1 State Contract)의 값을 업데이트한다.
ZK 롤업을 통한 보안 공유는 가장 큰 장점으로 영지식 증명의 성질에서 기인하는 비신뢰성*을 상속받아 옵티미스틱 롤업과 같은 신뢰 조건이 추가되지 않고, 레이어1의 검증자(Verifier Contract) 수학적으로 해당 실행에 따른 결과값(State 값)을 재실행하지 않고도 이를 신뢰할 수 있다. 따라서 이더리움 보안의 공유는 레이어 1의 검증자가 검증을 완료하였을 때 발생하며, 옵티미스틱 롤업과 달리 7일에 걸친 챌린지 기간이 없다.
롤업의 보안 공유를 요약해보자. 롤업은 이더리움의 온체인 데이터 저장소 (calldata)에 상태 루트를 이더리움 블록체인에 제출함으로써 이더리움과 보안을 공유하는 보안 공유 방법이다. 옵티미스틱 롤업은 도전 기간과 사기 증명에 의존하여 롤업 상태의 정확성을 보장하는 반면, ZK-롤업은 영지식 증명을 사용하여 동일한 목표를 달성한다.
*영지식 증명, Zero-Knowledge Proof 또한 ZK-Proof System이 가지는 성질, Completeness, Soundness에서 실행 결과를 수학적으로 믿을 수 있게 된다. 또한 Zero-Knowledgeness를 통해서 기록되는 양 및 필요한 컴퓨팅 리소스를 검증 리소스에만 한정하는 방식으로 비신뢰성 증명 시스템을 구현한다.
2. 보안을 공유하는 방법 2 — 리스테이킹
2-a. EigenLayer 개요
EigenLayer는 리스테이킹(Restaking)이라는 개념을 통해 탈중앙화 서비스가 이더리움 스테이커들의 보안을 이용할 수 있는 방법을 제시하는 프로토콜이다. 리스테이킹이란 말 그대로 합의 레이어에 스테이킹한 이더리움을 스마트 컨트랙트를 통해 EigenLayer에 다시 스테이킹하는 것을 말한다. EigenLayer의 오퍼레이터는 일정량의 리스테이킹된 이더리움을 위임받거나 직접 리스테이킹을 하여 EigenLayer의 특정 서비스에 opt-in을 하여 오퍼레이팅을 할 수 있다. 따라서 EigenLayer의 서비스들은 opt-in된 모든 오퍼레이터들이 가진 리스테이킹된 이더리움만큼의 보안을 확보할 수 있으므로 이더리움의 보안을 일부분 공유받을 수 있다.
EigenLayer의 보안 공유 방식은 후술할 코스모스의 Interchain Security와도 굉장히 유사하며, 이를 통해 초기에 자체 신뢰 네트워크 구축이 어려운 신규 프로젝트들은 기존에 높은 수준의 보안이 확보된 프로토콜의 보안 공유를 받을 수 있어 시작 단계에서 커다란 진입장벽을 하나 해결할 수 있다. 또한 리스테이킹을 하는 이더리움 스테이커들은 보안 공유에 대한 대가로 EigenLayer의 서비스들이 지불하는 수수료를 추가로 얻을 수 있다. 리스테이킹된 이더리움을 제공하고 프로토콜로부터 보상으로 수수료를 받는다는 점에서 EigenLayer는 마치 이더리움의 보안을 임대하는 마켓플레이스를 연상케 한다.
EigenLayer의 또다른 장점으로 프로토콜 의존성이 낮다는 점(Protocol Agnostic)을 들 수 있다. 이는 EigenLayer 위의 서비스들은 Layer 2와는 다르게 리스테이킹된 이더리움 지분을 통해 보안만을 공유받을 수 있기 때문이며, 이를 통해 이더리움과 별도의 합의 프로토콜 및 연산 레이어를 사용하는 서비스들에 보안 공유가 가능해진다. 하지만 이는 EigenLayer는 이더리움의 암호학적 연산에 대한 보안이 아닌 경제적 규모에 의한 보안만을 공유받는다는 것을 의미하며, 이더리움 컨센서스 레이어 전체에 해당되는 경제적 보안이 아닌 EigenLayer에 리스테이킹된만큼의 보안을 상속받게 되므로, 이에 대한 비판도 있을 수 있다.
이어서는 EigenLayer에서의 역할군에 대한 설명을 바탕으로 간단한 작동 원리를 알아보고, 여기서 엿볼 수 있는 리스테이킹의 방향성에 대해 논해보도록 하겠다.
2-b. Stakers
EigenLayer의 스테이커는 리스테이킹한 지분을 다른 오퍼레이터에게 위임하거나 직접 오퍼레이터로 참여가 가능하다. 리스테이킹에 있어서는 아래와 같이 2가지 방법이 존재한다.
i. LSD 프로토콜에 이더리움을 스테이킹하고 받은 LST(예: stETH)를 리스테이킹
StrategyManager 컨트랙트 호출을 통해 Strategy 컨트랙트에 스테이킹을 한다. EigenLayer는 유저가 위임한 리스테이크 이더리움이 슬래싱이 된 이력이 있을 경우 리스테이킹 이전에 Slasher 컨트랙트를 통해 확인을 진행한다. 리스테이크가 성공적으로 이루어질 경우 최종적으로 이후 위임이 어떻게 이루어졌는지 DelegationManager 컨트랙트를 통해 업데이트된다. 위 도식을 통해 간단한 작동 원리를 확인할 수 있다.
ii. EigenLayer를 통해 이더리움을 비콘 체인에 직접 스테이킹 (Native Restaking)
유저가 EigenPodManager.stake 컨트랙트를 호출하면 유저의 고유한 EigenPod 컨트랙트의 배포가 진행된다. **EigenPod**은 이더리움을 ETH2 Deposit Contract를 통해 비콘 체인에 예치한다. 예치 이후, EigenLayer의 비콘 체인 오라클을 통해 비콘 체인 스테이트 루트가 업데이트되면, 유저는 EigenPod.verifyWithdrawalCredentials 컨트랙트를 호출하여 **EigenPod**에 자신의 withdraw credential이 EigenPod을 가리키도록 하여 출금시 **EigenPod**으로 출금되도록 해야 한다. Native Restaking을 한 스테이커는 EigenPodPaymentEscrow를 통해 출금할 수 있지만 7일이 소요된다. 위 도식을 통해 간단한 작동 원리를 확인할 수 있다. (EigenPod.verifyWithdrawalCredentials 호출 이후 자세한 과정은 생략하였다.)
2-c. Operators
EigenLayer의 오퍼레이터는 EigenLayer의 서비스 및 미들웨어의 오퍼레이팅에 직접 참여하는 주체이다. 특징적인 것은 원하는 서비스에만 opt-in하여 오퍼레이터로 참여할 수 있다는 점이다. DelegationManager.registerAsOperator 컨트랙트를 통해 오퍼레이터로 등록이 가능하며 이때부터 스테이커들로부터 위임을 받을 수 있다. 스테이커와 마찬가지로 슬래싱이 된 이력이 있을 경우 오퍼레이터로 참여가 불가능하여 위임을 허용하기 이전에 Slasher 컨트랙트를 통해 확인을 진행한다.
2-d. Watchers
여타 옵티미스틱 롤업과 같이 제출된 모든 트랜잭션을 믿는 방식으로 구현된 EigenLayer에는 아직까지 클레임 사례는 발생하지 않았으며, 아직 클레임 사례를 제출하는 Watchers 엔티티는 존재하지 않는 것으로 확인했다. 다만 아이겐레이어 측에서는 미래에 Watchers 풀을 개발하여 롤업 클레임을 관찰하고 잘못된 클레임을 발견했을 때 사기증명을 수행하고 해당 클레임을 반증하는 역할을 맡길 것이라 밝힌 바 있다.
2-e. Services / Middleware (AVS)
리스테이킹된 경제적 보안을 기반으로 EigenLayer 위에 생길 다양한 서비스를 AVS라고 한다. 다만 여기서 특이한 점은 각 서비스들이 오퍼레이터에 대해 자체적인 슬래싱 조건을 만들어야 한다는 점이다.
보안을 공유하는 주체가 되는 오퍼레이터들은 서비스에 opt-in을 하기 이전에 슬래싱 조건에 대해 확인을 하고 Slasher.optIntoSlashing 컨트랙트를 통해 opt-in을 진행할 수 있으며, 이 과정에서 AVS의 ServiceManager 컨트랙트는 특정한 조건에서 오퍼레이터를 슬래싱할 권한을 얻게 된다.
2-f. 아이겐레이어를 통한 자율적인 보안 공유 시장 형성이 예상
이러한 구조를 통해 비춰볼 수 있는 EigenLayer의 목표는 무엇일까? 바로 누구나 리스테이크를 할 수 있고, 누구나 오퍼레이터로 참여할 수 있으며, 누구나 EigenLayer에 자체 신뢰 네트워크의 구축 필요 없이 서비스를 구현할 수 있는 permissionless한 플랫폼을 구축하려 한다고 예상된다.
특히 오퍼레이터가 어떤 서비스에 opt-in을 할지 자유롭게 선택할 수 있다는 것과 서비스가 자체적인 슬래싱 조건을 수립해야 한다는 점에서 자율적인 신뢰를 바탕으로 한 보안 공유 시장을 형성하고자 하는 아이겐레이어의 지향점을 엿볼 수 있었다.
3. 보안을 공유하는 방법 3 — 네이티브 보안 공유
보안 공유를 체인 설계 때부터 고민했던 이들이 있다. 바로 네이티브 보안 공유 설계를 가진 프로토콜들이다. 여기선 다수의 독립된 블록체인이 특정 규약이나 체인에서 제공하는 공통 보안 인프라를 공유받고, 보안을 대여해주는 체인은 토큰을 스테이킹하는 검증자들에 의해 강화된다. 본 글에서는 코스모스에 적용될 ICS(Interchain Security)와 폴카닷의 Parachain-Relaychain, 두가지 사례를 통해 네이티브 체인 설계에서 어떻게 보안이 공유될 수 있는지에 대해 알아보도록 하겠다.
3–a. Cosmos — Interchain Security
코스모스 생태계에서 체인을 런칭한다는 것은, 자체 밸리데이터 셋을 구축해야 하기 때문에 상당한 허들이 존재하며, 코스모스는 허브의 보안 공유를 통해 이러한 진입장벽을 낮추고자 한다. 그 시작은 지난 3월 진행된 V9-Lambda Upgrade이다. 해당 업그레이드에 대한 이야기를 하기에 앞서, 코스모스의 Interchain Security에서 사용하는 용어들에 대해 먼저 정리를 하고 넘어가자.
- Shared Security: 지분증명 방식의 블록체인에서 해당 블록체인의 보안을 다른 블록체인 또는 오프체인 프로세스와 공유하는 기술들을 일컫는 말로, 옵티미스틱 롤업, ZK-롤업, 샤딩, 그리고 interchain security 등을 포함한다.
- Interchain Security: 코스모스 한정적으로 사용하는 용어로, IBC(Inter-Blockchain Communication)를 사용하여 보안을 공유하는 기술을 말한다.
- Replicated Security: 여러 블록체인들이 완전히 복제된 밸리데이터셋의 보안과 탈중앙화를 사용하는 방식의 Interchain Security를 말한다. Cross Chain Validation 또는 Interchain Security V1 이라고도 불린다.
언급된 세가지의 보안 공유 기술은 다음과 같은 포함 관계를 가지게 되며, 본 글에서는 도입 중에 있는 Replicated Security를 기반으로 코스모스에 도입될 ICS의 작동 방식에 대해 알아보도록 하겠다.
3-a-1. Replicated Security 개요
V9-Lambda Upgrade는 위에 언급된 기술 중, Interchain Security의 첫 단계인 Replicated Security의 구현을 진행한 업데이트이다. Replicated Security의 설명에 앞서, Provider Chain-Consumer Chain의 관계에 대한 이해가 필요하다. Interchain Security의 보안 공유에서 Provider Chain이란 보안을 제공하는 체인을 의미하며 Consumer Chain은 해당 보안을 대여하는 체인을 일컫는다. 보안에 대한 대가로 Consumer Chain은 가스비의 일부와 자체 토큰 인플레이션의 일부를 Provider Chain에 제공하며 코스모스 허브가 현재 Provider Chain의 역할을 하고 있다. Provider Chain과 Consumer Chain은 Consumer Chain의 시작과 동시에 생성되는 단일한 IBC Transfer Channel을 통해 서로 정보 전달 및 토큰 교환을 하며, 이 과정에서 Interchain Security 모듈을 이용한다.
Replicated Security의 특징은 이름에 걸맞게 Consumer Chain이 Provider Chain과 완전 동일한 밸리데이터셋을 가진다는 점이다. Consumer Chain은 IBC Transfer Channel을 통해 주기적으로 코스모스 허브로부터 최신의 밸리데이터셋에 대한 정보가 담긴 IBC packet을 받고 이와 동일하게 자체 밸리데이터셋 정보를 업데이트한다. 따라서, 코스모스 허브 밸리데이터들은 여러 Consumer Chain들을 동일한 ATOM 지분으로 동시에 검증할 수 있는 권한 및 의무를 가지게 된다. 또한 Consumer Chain 공격을 위해서는 코스모스 허브 공격에 필요한 ATOM 지분과 동일한 ATOM 지분을 필요로 하기에 두 체인의 공격 비용이 동일해진다. 이를 통해 Consumer Chain은 자체 밸리데이터셋을 구성할 필요 없이 코스모스 허브의 보안으로부터 보호를 받을 수 있다. 이러한 시스템이 어떠한 방식으로 운영되는지 Replicated Security의 구현상의 특징 4가지에 대해 살펴보자.
3-a-2. Replicated Security 작동 방식
1) Key Assignment
Replicated Security에서 코스모스 허브와 Consumer Chain들의 밸리데이터 노드가 같은 consensus key를 사용한다면 Consumer Chain의 consensus key가 손상되었을 때 코스모스 허브의 밸리데이터 노드 또한 영향을 받는다는 문제가 있다. 따라서 Replicated Security에서는 밸리데이터들이 체인별 노드마다 별도의 consensus key를 사용하도록 설계되어 있다. Interchain Security 모듈은 각 Consumer Chain마다 key 할당을 위한 쿼리와 트랜잭션을 지원한다. 코스모스 허브의 밸리데이터들은 AssignConsumerKey 트랜잭션을 통해 Consumer Chain에서 어떠한 consensus key를 사용해 검증에 참여할지 지정할 수 있다.
2) Reward Distribution
앞서 기술한 것과 같이 Consumer Chain은 Provider Chain의 보안 공유에 대한 보상으로 주기적으로 distribution event를 통해 가스비 및 자체 토큰 인플레이션의 일부를 Provider Chain에 제공해야 한다. 이를 위해 Distribution 모듈을 이용하며, 각 블록의 시작마다 이전 블록의 보상이 Distribution 모듈에 축적된다. Distribution 모듈은 정해진 블록 개수마다 축적된 보상을 IBC Transfer Channel을 통해 packet 형태로 전송한다. Provider Chain에 전송해야 하는 보상의 비율, Distribution event가 일어나는 주기 등은 Consumer Chain으로서 등록을 위한 Provider Chain에의 거버넌스 프로포절에 대부분 기술되어야 하며 Reward Distribution에 사용될 파라미터들은 다음과 같다.
consumer_redistribution_fraction: Distribution event에서 Consumer Chain → Provider Chain으로 보내질 토큰 비율blocks_per_distribution_transmission: Distribution event가 진행되는 블록 주기transfer_timeout_period: Consumer Chain의 reward distribution IBC packet이 타임아웃되는 기간distribution_transmission_channel: Consumer Chain의 보상을 받기 위한 IBC 채널 주소provider_fee_pool_addr_str: Consumer Chain의 보상을 받기 위한 Provider Chain의 pool 주소
3) ICS Provider Proposals
Replicated Security에서 사용되는 3가지 종류의 On-Chain 거버넌스 프로포절은 다음 세가지가 있다.
ConsumerAdditionProposal: 새로운 Consumer Chain을 추가하기 위해 사용되는 프로포절이며,spawn_time,chain_id,consumer_redistribution_fraction등 Consumer Chain으로서의 역할을 하기 위한 정보들이 기입된다.ConsumerRemovalProposal: 현재 등록되어 있는 Consumer Chain을 제거하기 위해 사용되는 프로포절이며,stop_time,chain_id,title등의 정보들이 기입된다.EquivocationProposal: Consumer Chain에서 특정 밸리데이터가 이중서명하는 경우 슬래싱을 위해 Consumer Chain이 Provider Chain에 보내는 프로포절이다.
4) Consumer Initiated Slashing
i. Downtime Infractions
- 밸리데이터가 일정 시간 이상 동안 검증에 참여하지 않을시 Consumer Chain에서 Provider Chain으로 신고를 한다. 신고가 되는 즉시 Provider Chain은 해당 밸리데이터를 jail에 보낸다. 밸리데이터는 jail에 있는 동안 블록 보상을 받을 수 없으며, unjail이 되기 위해서는 jailing period 이후에 unjail 트랜잭션을 Provider Chain에 전송해야 한다.
ii. Double-signing (Equivocation)
- 특정 밸리데이터의 이중서명이 발견되었을 때, Downtime Infractions와는 다르게 해당 밸리데이터는 즉시 처벌되지 않는다. Consumer Chain은 밸리데이터의 이중서명이 발견되면 증거를 포함해 Provider Chain에 **
EquivocationProposal**을 제출한다. 이후 프로포절이 거버넌스에 의해 통과되면 해당 밸리데이터는 모든 Consumer Chain에서 슬래싱된다.
3-a-3. Replicated Security의 한계와 개선 방향
그러나 Replicated Security는 모든 Consumer Chain과 Provider Chain이 동일한 밸리데이터들로 이루어진다는 점에서 명확한 한계점을 가지고 있다. 먼저, Consumer Chain이 Provider Chain 이상으로 성장을 하게 되었을 때, 가용한 컴퓨팅 파워가 Provider Chain의 밸리데이터셋에 한정되어 있기 때문에 그 이상의 Scale-up이 불가능하다는 단점이 있다.
또한, Provider Chain의 밸리데이터가 중앙화 될 수 있다는 문제점이 존재한다. 현재 코스모스의 Replicated Security는 모든 밸리데이터가 Consumer Chain의 검증에 반드시 참여해야 한다. 이는 추가되는 Consumer Chain에 충분한 보안의 제공을 위함이다. 그러나 Consumer Chain의 수가 늘어남에 따라 밸리데이터들에게 요구되는 컴퓨팅 파워는 이에 비례하여 증가하게 될 것이다. 따라서 소규모 밸리데이터들은 점차 참여가 어려워져 Provider Chain 및 Consumer Chain들의 검증을 대규모 밸리데이터가 독점함에 따른 중앙화 문제가 생길 수 있다.
이를 위한 해결방안으로 Replicated Security를 적용한 V9-Lambda Upgrade 이후 코스모스의 Interchain Security의 로드맵에는 다음 2가지 기능의 추가가 예정되어 있다.
- Provider Chain 외부의 밸리데이터들도 Consumer Chain의 검증에 참여 가능
- Provider Chain의 밸리데이터들이 특정 Consumer Chain에 대한 opt-in 선택 가능
1번 기능의 추가를 통해 Consumer Chain의 Scale-up이 어렵다는 한계가 해소될 것이며, 2번 기능을 통해 Consumer Chain의 개수에 비례한 과도한 컴퓨팅 파워의 요구 문제 또한 해결이 가능할 것으로 생각된다.
3-a-4. ICS를 통한 진입장벽 해소 및 ATOM의 가치 부양
1) 신규 앱체인의 보안 부담 및 진입장벽 해소
결국 코스모스 허브가 Interchain Security(ICS)를 통해 달성하고자 하는 목표는 앱체인 운영으로 인한 진입장벽 해소다. 이를 위해 기존 코스모스 허브의 밸리데이터셋을 Consumer Chain에 제공하여 보안을 공유하게 되며, 이를 통해 신규 앱체인은 자체적인 밸리데이터셋을 구축할 필요가 없어 안정적인 초기 서비스 런칭이 가능해 지는 것이다.
2) ‘Security as a Service’를 통한 ATOM의 가치 부양
ICS 도입은 ATOM의 가치 부양에도 도움이 된다. Delphi Digital에 의하면 ATOM은 프로토콜들 수익이 현저히 적은데, 코스모스의 Interchain Security에서의 ATOM 스테이킹을 통해 밸리데이터들이 Consumer Chain으로부터 추가 수익을 낼 수 있기 때문이다.
3) Hub Minimalism
코스모스는 또한 각자 다양한 역할을 담당하는 Consumer Chain들을 런칭해 Hub Minimalism을 달성하고자 하며, 특히 코스모스 허브를 통해 타 Consumer Chain들에 보안을 제공하는 보안의 허브 역할을 하며 향후 Defi, Rollup 허브 등 특수한 역할을 수행하는 앱체인들을 통해 단순화를 이룰 수 있게 된다. 기존의 허브로서의 코어 보안 모듈 역할을 톡톡히 해낼 수 있게 되는 것이다.
3-b. Polkadot — Sharded Execution
폴카닷은 보안 허브 역할을 하는 릴레이체인과 각종 애플리케이션이 구축될 수 있는 파라체인의 구조로 이루어진 레이어 1 블록체인으로, Validator로의 위임을 기반으로 한 NPoS 합의 메커니즘을 도입하고 있다. 보안 공유의 핵심엔 파라체인에서 실행된 트랜잭션을 릴레이체인에선 검증하게 되는 샤딩 실행 환경(Sharded Execution Environment)이 있으며, 아래와 같이 릴레이체인을 수많은 파라체인들이 감싸는 파라체인 프로토콜이 존재한다.(체인의 스펙에 대해 더 알고 싶다면 디사이퍼의 폴카닷-내려다보기를 참조하자).
본 글에서는 릴레이 체인이 파라체인에게 보안을 공유하는 방식에 대해 다룰 예정이며, 이를 위해 폴카닷의 공유 보안의 기틀이 되는 세가지 요소에 대해 먼저 소개하려 한다. 바로 1)공통된 Wasm(Webassembly) 런타임과 2)파라체인 프로토콜(Parachain Protocol) 그리고 보안 허브로 작동하는 3)릴레이 체인이다.
1) 공통된 Wasm(WebAssembly) Runtime 환경
폴카닷은 파라체인, 릴레이체인 모두가 Wasm으로 통일된 런타임 환경을 공유한다. 일각에서는 성능, 보안성, 다양한 언어에 대한 지원, Platform Agnostic한 웹어셈블리의 특성 등을 강조하지만, 보안 공유 차원에서 드러나는 가장 큰 장점은 통일된 실행 환경 조건이 된다. 즉, 파라체인에서 실행된 비즈니스 로직이 별다른 변환 과정을 거치지 않아도 동일한 컴파일 환경이 마련되므로 폴카닷 내에선 모두 동일한 실행 결과를 기대할 수 있게 되는 것이다. 특히 폴카닷에선 각각의 파라체인의 목적별로 STF(State Transition Function, 상태 전이 함수)*를 다르게 구성할 수 있는데, 릴레이 체인에서 파라체인의 후보 블록을 검증할 때 있어서 릴레이 체인에 기록된 파라체인별 STF를 실행하여 이를 검증할 수 있다.
Rust를 활용하여 작성된 간단한 블록의 STF를 알아보자: MyStorageValue라는 단일 스토리지 항목을 가지고 있으며, 이는 set_value라는 호출 가능 함수를 통해 수정할 수 있다. 이 함수는 u32 타입의 value를 입력받아, ensure_signed(origin)을 사용하여 함수 호출이 서명되었는지 확인하고, 만약 참이라면 MyStorageValue::put(value)를 사용하여 value를 MyStorageValue에 저장한다.
// FRAME 라이브러리로부터 필요한 트레잇과 모듈을 import
use frame_support::{decl_module, decl_storage, dispatch::DispatchResult};
// Config 트레잇은 이 런타임 모듈에서 사용될 타입과 상수를 제공
pub trait Config: frame_system::Config { }
// `decl_storage!` 매크로는 모듈 내의 스토리지 항목을 선언하는데 사용됨
decl_storage! {
// Store 트레잇은 모듈의 스토리지 항목을 정의
trait Store for Module<T: Config> as MyModule {
// 스토리지 항목 MyStorageValue는 u32 타입으로 선언되며, my_storage_value라는 getter 함수를 가짐
pub MyStorageValue get(fn my_storage_value): u32;
}
}
// `decl_module!` 매크로는 모듈 내에서 호출 가능한 함수를 선언하는데 사용됨
decl_module! {
// Module 구조체는 호출 가능한 함수들을 정의하고, 이들이 모듈의 스토리지 항목과 어떻게 상호작용하는지를 정의
pub struct Module<T: Config> for enum Call where origin: T::Origin {
// u32 타입의 값을 인자로 받는 set_value라는 공개 호출 가능 함수
pub fn set_value(origin, value: u32) -> DispatchResult {
// 함수가 서명된 원본에 의해 호출되었는지 확인하고, 그렇지 않다면 에러를 반환
let _ = ensure_signed(origin)?;
// 입력받은 값을 스토리지 항목 MyStorageValue에 Input 값으로 전달
MyStorageValue::put(value);
// Ok(())를 반환하여 함수 실행이 성공적으로 이루어졌음을 표시
Ok(())
}
}
}예시의 스토리지 함수에서와 같이, 갖가지 비즈니스 로직의 기반이 되는 STF가 검증의 대상이 되는 파라체인과 이를 검증하는 릴레이체인 모두에 기록된다. 결국 양 체인에 동일한 런타임 환경이 조성되어 있기 때문에 검증의 근간이 되는 STF의 실행 환경이 동일하게 조성되며, 이는 보안 공유에도 상당한 이점을 주게 되는 것이다.
*state transition function (STF) 은 블록체인에서의 스테이트를 변경하는 함수로, 폴카닷에서는 파라체인별 필요한 비즈니스 로직에 따라 별도의 STF가 커스터마이징이 가능하다. 특히 확장성을 위해 사용되는 파라체인의 STF에선 검증을 얼마나 효율적으로 할 수 있느냐가 큰 중요도를 가지게 된다.
2) Parachain Protocol
파라체인 프로토콜은 파라체인에서 릴레이체인까지 완결성을 확보하기 위해 사용되는 서브시스템의 모임으로, 그 과정에서 사용되는 Collation, Backing, Availability, Approval Checking, Disputes과 같은 다양한 세부 단계(Subsystem)의 집합으로 정의된다. 각 서브시스템이 작동하는 단계에 따른 트랜잭션의 흐름을 아래 ‘파라체인 트랜잭션 쫒아가기’ 부분에서 설명하도록 하겠다.
3) Relay Chain: The Security Hub
릴레이체인은 수많은 파라체인을 조율(Coordination)하며 보안만을 담당하는 폴카닷의 중앙 기록보관소 역할을 한다. 이때 릴레이체인 자신만의 블록 생성자(Block Producers), 파라체인 검증인(Parachain Validators = Validators), 파라체인 전체의 합의 메커니즘과 완결성을 관리하는 역할을 맡게 되며, 이것의 일환으로 스마트 컨트랙트와 같은 다양한 애플리케이션 레이어에 해당되는 작업을 하지 않고 단순히 파라체인의 완결성을 위한 블록 생성과 검증에 매진한다. 이더리움과 달리 메인 체인이 스마트 컨트랙트 지원을 하지 않는 것도 릴레이 체인의 목적이 파라체인 트랜잭션의 검증이 되기 때문이다.
3-b-1. 파라체인 트랜잭션 쫒아가기
폴카닷의 릴레이 체인은 공유 보안 또는 풀 보안이라고 하는 프로세스를 통해 파라체인과 보안을 공유한다. 이 프로세스를 통해 파라체인은 자체 합의 및 검증자 세트를 개발하고 유지 관리할 필요 없이 전체 폴카닷 네트워크의 보안을 활용할 수 있다. 이제 앞서 언급된 파라체인 프로토콜의 각 세부 단계(Subsystems): Collation, Backing, Availability, Approval Checking, Disputes 를 살펴보며 파라체인에서 생성된 트랜잭션이 릴레이 체인에서의 검증을 거치며 완결성을 가질 수 있는 이유에 대해 알아보자.
1) 콜레이션(Collation)
콜레이터라는 엔티티에 의해 파라체인의 트랜잭션을 모아 릴레이체인에 제출할 후보 블록(Candidate Block)을 생성하는 과정이다. 콜레이터들은 트랜잭션의 순서를 정하고 실행한 후 이에 대한 블록을 생성한다는 점에서 마이너 또는 검증인과 유사하다고 볼 수 있으나, 실질적인 검증은 릴레이 체인에서 이루어진다는 점에서 롤업의 시퀀서(Sequencer) 혹은 운영자(Operator)와 더 비슷한 면이 있다.
사용자가 거래를 파라체인 네트워크에 제출하면, 거래 풀에서 이를 콜레이터가 보고 트랜잭션 블록을 만든다. 이때 모든 트랜잭션을 전부 조합하지 않고, 해당 블록 타임 동안 실행된 트랜잭션의 일부 데이터만을 포괄하는 부분 머클트리(Partial Merkle Tree)를 생성한다. 이러한 부분 머클트리는 검증 증명(PoV)****로 사용될 뿐만 아니라 데이터의 일부분만을 담고 있어 검증에 필요한 데이터의 크기를 줄이는데 일조한다.
이렇게 수집한 트랜잭션 블록과 PoV를 입력으로 파라체인의 런타임(체인의 상태 전환 함수(STF) 및 거래 처리에 필요한 기타 로직을 포함하는 Wasm(WebAssembly 실행 파일)을 거쳐 콜레이터는 업데이트된 상태와 검증 증명(PoV)을 포함하는 후보 블록***을 생성한다.
2) 백킹(Backing)
콜레이션 과정 이후 릴레이 체인의 검증자들이 콜레이트된 블록 후보의 유효성을 검증하는 과정이다. Polkadot에서는 각 패러체인에 할당된 검증자 그룹이 있는데, 이를 패러체인의 백킹 검증자라고 하며, 이들은 릴레이체인의 블록 생성 주기마다 BABE 무작위 비콘과 VRF를 사용하여 랜덤 배정된다. 이렇게 배정된 검증자들은 콜레이터로부터 제공된 PoV를 확인하고, 블록이 유효하면 그들의 DOT 토큰을 이 블록의 유효성에 걸어 이를 보증(Back) 한다
3) 가용성(Availability)
백킹 과정 이후에는 블록이 릴레이 체인에 포함될 수 있는 것으로 간주된다. PoV는 이레이져 코딩(Erasure Coding)**이라는 과정을 거쳐 네트워크의 모든 검증자들 사이에 분배되는데, 분할된 조각은 일부 조각만으로도 전체 데이터를 복원할 수 있어 릴레이체인 전체에 해당 데이터가 유효(Available) 해진다. 앞서 후보 블록에 대한 증빙자료(candidate receipt)를 릴레이체인의 트랜잭션 큐로 보내기 전, 검증인은 파라체인 블록에 대한 이레이져 코딩을 연산해야 한다.
4) 승인 확인(Approval Checking)
추가 검증자들(즉, 백킹 검증자가 아닌 검증자들)이 블록의 유효성을 재확인하는 과정이다 이들 검증자들은 가용성 단계에서 분배된 이레이져 코딩 조각들을 사용하여 PoV를 재구성하고, 블록이 패러체인의 상태 전이 규칙을 준수하는지 확인한다. 이 단계에서 블록이 유효하다고 판정되면, 블록은 최종적으로 승인되고, 릴레이 체인의 규칙에 따라 (GRANDPA) 캐노니컬 블록으로 간주되어 완결성을 갖는다.
5) 분쟁(Disputes)
분쟁 단계는 잘못된 블록이 승인되거나, 블록의 유효성에 대한 불일치가 발생할 경우에 필요한 메커니즘이며, 이는 블록의 유효성에 대한 불일치를 해결하기 위한 절차다. 분쟁이 발생하면, 블록의 유효성에 걸린 모든 DOT 토큰은 슬래싱되어 손실될 수 있어 잘못된 블록을 보증한(Backing) 검증자는 그들의 DOT 토큰을 잃게 된다. 이와 같은 방법으로 폴카닷은 블록의 유효성에 대한 분쟁이 발생할 경우에도 릴레이 체인과 파라체인 간의 공유 보안 모델을 유지한다.
이렇게 단일 파라체인에서 발생한 트랜잭션이 폴카닷의 실행환경, 파라체인 프로토콜, 릴레이체인 구성에 각각의 세부 단계를 통해 통해 완결성이 확보되고 보안이 공유되는 과정에 대해 알아봤다. 이어서는 상호운용성(Interoperability)을 강조한 폴카닷에서 사용되는 XCM / XCMP에 대해 알아보고 어떻게 여기서도 완결성 및 릴레이 체인의 보안을 공유받게 되는지 설명하도록 하겠다.
*BABE (Blind Assignment for Blockchain Extension): BABE는 Polkadot의 릴레이 체인을 위한 블록 생성 메커니즘이다. 이는 슬롯 기반 프로토콜로, 검증자들이 슬롯에 의사 무작위로 할당되어 블록을 생성한다. 이 할당은 검증 가능한 무작위 함수(VRF)를 사용하여 예측할 수 없고 안전하게 만들며, BABE는 공정한 검증자 선택 과정을 보장하는 무작위 비콘 기능을 가진다.
**이레이져 코딩(Erasure coding): 파라체인 후보 블록이 릴레이 체인에 제출되기 전에, 이레이져 코딩이라는 기술을 사용하여 더 작은 조각으로 분할된다. 이 프로세스는 일부 조각이 손실되거나 손상되더라도 남아있는 조각의 작은 수에서 원본 데이터를 다시 구성할 수 있도록 보장한다.
***후보 블록(Candidate block): 후보 블록은 콜레이터에 의해 제안된 파라체인의 잠재적 블록이다. 콜레이터는 각각의 패러체인에 대한 거래와 상태 전환을 수집하고 집계하는 책임이 있으며, 이 데이터가 포함된 후보 블록을 생성한다. 이후 후보 블록은 릴레이 체인의 검증자에게 승인 및 포함을 위해 제출된다.
****PoV (Proof of Validation): 검증 증명은 폴카닷에서 검증자가 블록의 모든 거래와 상태 전환을 다시 실행할 필요 없이 후보 블록의 정확성을 확인할 수 있게 하는 메커니즘이다. 이는 후보 블록에 PoV를 첨부하여 이루어지며, 검증자가 효율적으로 블록의 유효성을 확인할 수 있는 충분한 정보를 제공한다. 대표적인 예시로 전체 거래의 일부 데이터만을 포괄하는 부분 머클트리(Partial Merkle Tree)가 있다.
*****VRF (검증 가능한 난수 함수): VRF는 BABE 합의 알고리즘에서 사용되는 암호학적 기본 요소로, 검증 가능한 난수를 생성한다. 검증자는 개인 키를 사용하여 난수를 생성하고, 다른 사람들은 검증자의 공개 키를 사용하여 이를 검증할 수 있다. 이 메커니즘을 통해 무작위 비콘이 안전하고 예측할 수 없으며 검증 가능함을 보장할 수 있다.
3-b-2. 크로스체인 메세징의 완결성
폴카닷에서 Cross-Chain Message Passing (XCMP) 프로토콜은 파라체인 간의 통신을 가능하게 하는 프로토콜을 의미하며, 이것의 모체가 되는 Cross-Chain Messaging Format (XCM)은 이러한 메시지의 형식과 의미를 정의하는 메시징 포맷이 된다. 특이한 점은 XCMP를 통해 크로스체인 메세징이 진행된 트랜잭션에도 앞서 설명한 파라체인 → 릴레이체인의 완결성이 보장된다는 것. 본 문단에서는 XCM이 폴카닷의 블록 생성 단위와 어우러져 어떻게 릴레이 체인의 블록 생성과 함께 완결성을 기록할 수 있는 것인지 간단하게 살펴보자.
1) XCM — Collation
크로스체인 메시지가 한 파라체인에서 다른 파라체인으로 전송될 때, 먼저 파라체인의 콜레이터(Collator)에 의해 Candidate Block에 포함된다. 이때 릴레이 체인의 검증자는 이 블록을 검증하고 릴레이 체인에 포함시키는 프로세스를 수행하게 된다.
2) XCM — Backing
이후 보내는 파라체인의 Candidate Block에 XCM 메시지가 포함되어 릴레이 체인에서 완결성이 확보되면, 해당 메시지는 수신 파라체인으로 전달된다. 받는 파라체인의 Collator는 XCM 메시지를 후보 블록에 포함시키며, 다시 릴레이 체인 검증자에 의해 검증 및 포함 프로세스를 거치게 된다.
3) XCM — Finality
결국 XCM 메시지는 앞서 알아본 과정처럼 파라체인의 후보 블록이 릴레이 체인에 포함되는 릴레이 체인의 블록 생성 시간마다 완결성을 달성하게 된다.
맺으며: 보안 공유 시장의 태동인가, 단순 네러티브일까
트렌드: 보안 공유
지금까지 우리는 암호경제적 보안 개념에 대한 시리즈를 통해, PoS 합의 알고리즘을 기반으로 한 체인의 보안을 향상시키는 유동 스테이킹(liquid staking)에 대해 알아보고, 이를 바탕으로 확장된 보안을 공유할 수 있는 방법인 롤업(rollups)과 리스테이킹(restaking)에 대해 알아보았다. 또한 코스모스의 인터체인 시큐리티와 폴카닷의 공유 실행 환경 아키텍쳐처럼 프로토콜 설계 초기부터 타 체인에 대한 보안 공유에 방점을 둔 네이티브 보안 공유 방법에 대해서도 공부해 보았다.
특히나 최근, ‘암호경제적 보안을 공유한다’ 는 개념은 최근 크립토 시장에서 가장 핫한 주제가 되고 있다. 최근 이더리움의 확장성 문제를 해결하기 위해 옵티미즘, 아비트럼, ZkSync 등 옵티미스틱, ZK 롤업을 활용한 다양한 레이어 2 솔루션들은 이미 다수의 이용자들을 확보했으며, EigenLayer의 경우에도 백서 공개와 함께 좋은 호응을 받고 첫 서비스로 데이터 가용성 레이어인 EigenDA를 준비중이다. 코스모스 또한 Replicated Security를 사용하는 첫 앱체인인 Neutron의 테스트넷을 진행하고 있다. 그야말로 보안을 상품화하여 판매하는 시장이 실제로 시장 네러티브를 이끌고 있는 것이다.
보안 공유 네러티브와 지속 가능성에 대한 의문
그러나 이로 인해 우리에게는 몇가지 질문이 남는다. 과연 이러한 보안 공유의 개념이 단순한 새로운 프로토콜 및 프로젝트에게 충분한 보안을 제공할 수 있을 만큼 완벽한 것인가? 암호경제적 보안은 ‘암호학’과 ‘경제학’을 포괄하는 광의의 프로토콜 보안 개념이다. 어쩌면 유동 스테이킹 프로토콜과 아이겐레이어와 같이 단순히 경제학적 보안을 레버리징 하는것은 ‘암호학’이 아닌 ‘경제학’적 요인에 과다하게 기대고 있을지도 모르기 때문이다. 특히 최근 비탈릭 뷰테린이 Don’t overload Ethereum’s consensus 라는 아티클에서 오라클 등 주관적인 판단이 요구되는 것에 이더리움 컨센서스 레이어의 ‘경제적' 보안만을 빌려주는 보안 공유의 형태는 소셜 컨센서스로 인한 하드포크가 일어날 수도 있다는 위험성을 강조하기도 했다.
또한 실질적인 수요가 있는 상황인지도 의문이다. 아이겐레이어가 메인넷을 출시하고 출시 직후 9600ETH를 모금하는데 성공했다. 하지만 암호경제적 보안을 공유받아야 할 시장에서의 수요는 충분할까? 단순히 스테이킹된 이더리움으로 추가적인 이자율을 받기 위한 수요 없는 공급으로 끝나진 않을까? 보안 공유 시장은 시장 검증 차원에서 해결해야 할 문제가 너무나도 많다.
따라서 롤업이 이더리움의 확장성 솔루션으로서 어느정도 시장성이 증명되고 있는 것처럼, 리스테이킹, 네이티브 보안 공유 체인 등, Shared Security를 필두로 한 다양한 솔루션들에 대한 꾸준한 수요가 발생해야만 ‘보안 공유’ 모델이 네러티브가 아닌 지속 가능한 BM이 될 수 있을 것이라 판단하며 글을 마치도록 하겠다.
Source
https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/docs
https://polkadot.network/blog/the-path-of-a-parachain-block
https://wiki.polkadot.network/docs/learn-parachains-protocol
https://polkadot.network/development/docs/
https://cosmos.github.io/interchain-security/introduction/overview
https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/README.md
https://forum.cosmos.network/t/proposal-187-accepted-v9-lambda-upgrade-with-replicated-security/8766
https://members.delphidigital.io/reports/cosmos-the-evolution-of-ibc#key-takeaways
