SCP 해석: 롤업 정형화를 벗어난 신뢰 없는 인프라 패러다임

2023.12.29

SCP 해석: 롤업 정형화를 벗어난 신뢰 없는 인프라 패러다임

SCP의 비전과 실제 응용은 신뢰를 필요로 하지 않는 새로운 세대의 인프라, 나아가 블록체인 구조가 아닌 연산 플랫폼을 구축하는 것이다.

2023.12.29 - 01:46:37

Web3 심층 보도에 집중하고 흐름을 통찰

SCP의 비전과 실제 응용은 신뢰를 필요로 하지 않는 새로운 세대의 인프라, 나아가 블록체인 구조가 아닌 연산 플랫폼을 구축하는 것이다.

글: 안개달, Geeker Web3

서론: 본문에서는 다소 독특해 보이는 Web3 인프라 설계 패러다임인 스토리지 기반 컨센서스 패러다임(SCP, Storage-based Consensus Paradigm)을 전망적으로 소개하고자 한다. 이 제품 설계 모델은 이론적으로는 이더리움 롤업(Rollup)과 같은 주류 모듈형 블록체인 방식과 상당한 차이를 보이나, 실제 구현의 용이성 및 Web2 플랫폼과의 연계 난이도 측면에서 실현 가능성이 매우 높다. 왜냐하면 SCP는 처음부터 롤업처럼 좁은 구현 경로에 스스로를 제한하려 하지 않았기 때문이다. 대신 더 포괄적이고 개방적인 프레임워크를 통해 Web2 플랫폼과 Web3 인프라를 통합하려는 시도로서, 매우 창의적이고 상상력이 풍부한 접근이라고 할 수 있다.

다음과 같은 특성을 지닌 공용 블록체인 확장 솔루션을 가정해보자:

기존 Web2 애플리케이션이나 거래소와 동일한 속도를 제공하며, 기존의 공용 블록체인, L2, 롤업, 사이드체인 등을 모두 능가한다.
가스비가 없으며 사용 비용은 거의 0에 가깝다.
자금 보안 수준이 높아 중앙화된 기관(예: 거래소 등)보다 훨씬 안전하며, 롤업보다는 다소 낮지만 사이드체인 이상이다.
Web2와 동일한 사용자 경험(UX)을 제공하여, 블록체인의 공개키/개인키, 지갑, 인프라 등에 대한 이해 없이도 이용할 수 있다.

이러한 솔루션은 매우 매력적이다. 확장성 측면에서 이미 극한까지 도달했으며, Web3의 대중화(mass adoption)를 위한 견고한 기반을 마련함으로써 Web2와 Web3 간의 사용자 경험 격차를 사실상 해소하기 때문이다.

그러나 현실적으로 이러한 완벽한 조건을 충족하는 솔루션은 거의 존재하지 않는다. 주류 논의와 실천 사례가 너무 적기 때문이다.

앞서 언급한 확장성 문제는 단순한 서두일 뿐이며, 실제로 SCP는 확장성에 국한되지 않는다. 그 설계 영감은 비트코인, 이더리움 등의 공용 블록체인 확장 방안 및 커뮤니티 토론에서 유래했지만, SCP의 비전과 실제 응용 목적은 새로운 세대의 트러스트리스 인프라를 구축하고, 심지어는 블록체인이 아닌 구조의 컴퓨팅 플랫폼을 만들겠다는 것이다.

SCP의 기본 구성 요소 및 작동 원리

일반적으로 SCP 역시 이더리움 및 Celestia 커뮤니티에서 말하는 '모듈형 블록체인'과 마찬가지로, 데이터 가용성 계층(DA Layer), 실행 계층(Execution Layer), 컨센서스 계층(Consensus Layer), 정산 계층(Settlement Layer) 등으로 모듈화된다.

데이터 가용성 계층(Data Availability Layer): 널리 인정되고 오랜 시간 검증된 공용 블록체인 또는 스토리지 인프라가 담당한다. 예를 들어 이더리움, Arweave, Celestia 등이 해당된다.
실행 계층(Execution Layer): 사용자의 거래를 수신하고 실행하는 서버로, 사용자가 서명한 거래 데이터를 일괄적으로 DA 계층에 제출한다. 롤업의 정렬기(sequencer)와 유사하다. 그러나 실행 계층은 반드시 블록체인의 체인 구조를 가질 필요는 없다. 완전히 Web2 데이터베이스 + 컴퓨팅 시스템 형태일 수 있으나, 전체 컴퓨팅 시스템은 오픈소스여야 하며 투명성이 보장되어야 한다.
컨센서스 계층(Consensus Layer): 일련의 노드들로 구성되며, 실행 계층이 DA 계층에 제출한 데이터를 가져와 동일한 알고리즘으로 연산을 수행하여 실행 계층의 출력 결과가 올바른지 확인한다. 또한 실행 계층의 재해 복구용 중복 역할을 수행한다. 사용자는 컨센서스 계층 각 노드가 반환하는 데이터를 직접 읽어, 실행 계층의 사기 행위 여부를 확인할 수 있다.
정산 계층(Settlement Layer): 일련의 노드와 다른 체인 상의 스마트 컨트랙트 또는 주소로 구성되어, 사용자의 입금 및 출금 요청을 처리한다. 다소 크로스체인 브릿지(cross-chain bridge)와 유사한 방식이다. 정산 계층 노드는 멀티시그 컨트랙트 또는 TSS 기반 주소를 통해 입금 주소의 출금 기능을 제어한다. 사용자는 자산을 해당 체인의 지정 주소로 입금하고, 출금 시 요청을 보내면 정산 계층 노드가 데이터를 확인한 후 멀티시그 또는 TSS를 통해 자산을 출금한다. 정산 계층의 보안 수준은 채택된 크로스체인 메커니즘에 따라 결정된다.

SCP의 실천 프레임워크

다음 프레임워크를 통해 SCP 패러다임을 이해할 수 있다. SCP 프레임워크를 충족하는 제품은 입금, 송금, 출금, 스왑(swap) 등의 주요 기능을 갖추며 추가적으로 확장될 수 있다. 아래는 그러한 제품의 원리도:

해당 프로젝트는 DA 계층으로 영구 저장 인프라인 Arweave를 사용하고 있으며, 그림의 큰 원으로 표현된다.
코디네이터(Coordinator)는 곧 실행 계층이다. 사용자는 거래를 코디네이터에 제출하며, 코디네이터는 이를 실행하고 결과를 표시한 후 사용자의 원본 입력 데이터를 일괄적으로 DA 계층에 제출한다.
디텍터(Detector): Arweave에서 코디네이터가 제출한 원본 거래 데이터를 가져와 코디네이터와 동일한 알고리즘을 사용해 데이터와 결과를 검증한다. 디텍터 클라이언트 역시 오픈소스이며 누구나 실행할 수 있다.
왓치맨(Watchmen): 일련의 디텍터 노드들로 구성되며, 출금 시스템의 멀티시그를 관리한다. 거래 데이터를 기반으로 출금 요청을 검증하고 승인한다. 또한 제안(proposal) 서명도 담당한다.

전체 시스템은 체인 외부에서 합의를 이루고 있음을 알 수 있다. 이것이 바로 스토리지 기반 컨센서스 패러다임의 핵심 — 즉, 블록체인 형 노드 컨센서스 시스템을 버리고, 실행 계층이 번거로운 컨센서스 교환 및 확인 절차에서 벗어나 오직 하나의 서버처럼 작동하게 함으로써 거의 무제한의 TPS와 경제성을 달성한다. 이 점은 롤업과 매우 유사하지만, SCP는 롤업과 다른 길을 걷는다. 즉, 확장성 전용 사례에서 나아가 Web2에서 Web3로의 새로운 전환 모델로 전환을 시도하는 것이다.

앞서 언급한 코디네이터는 하나의 서버이지만, 이는 코디네이터가 마음대로 행동할 수 있다는 의미는 아니다. 롤업의 정렬기와 마찬가지로, 사용자가 제출한 원본 데이터를 Arweave에 일괄 제출한 이후에는 누구든지 디텍터 프로그램을 실행해 이를 검증하고 코디네이터가 반환한 상태와 비교할 수 있다. 어떤 면에서 이는 인스크립션(inscription) 애플리케이션의 아이디어와 일맥상통한다.

이러한 아키텍처 하에서 중앙화된 서버나 데이터베이스는 근본적인 장애물이 되지 않는다. 이것이 SCP 패러다임의 또 다른 특징으로, '중앙화'와 '단일 실체'라는 두 개념을 분리하는 것이다 — 트러스트리스 시스템 내에서도 중앙화된 구성 요소가 존재할 수 있으며, 심지어 핵심 부품일 수도 있지만, 전체 시스템의 트러스트리스 특성에는 영향을 주지 않는다.

우리는 다음과 같은 슬로건을 외칠 수 있다 — "차세대 트러스트리스 인프라는 반드시 컨센서스 프로토콜에 의존할 필요는 없지만, 오픈소스 시스템과 P2P 노드 네트워크를 포함해야 한다".

사람들이 블록체인을 발명하고 사용한 초점은 트러스트리스, 원장 일치, 위조 불가, 추적 가능성 등 늘 반복되는 기본 원칙에 있다. 이는 비트코인 백서에 명확히 기술되어 있다. 하지만 이더리움 이후로는, 기존 공용 블록체인의 확장 방안이든, 롤업이든, 모듈형 블록체인이든 우리는 모두 고정관념에 빠져들었다: 우리가 만드는 것은 반드시 하나의 블록체인이어야 한다(노드 간 컨센서스 프로토콜로 구성된), 아니면 최소한 블록체인처럼 보이는 구조(블록체인 데이터 구조는 가지지만 노드 간 직접적인 컨센서스 메시지를 주고받지는 않음)여야 한다.

그러나 현재 SCP 프레임워크를 보면, 블록체인이 아니더라도 트러스트리스, 원장 일치, 위조 불가, 추적 가능성 등의 요구사항을 모두 달성할 수 있다. 물론 더 명확한 구현 세부 사항이 전제되어야 한다.

실행 계층

실행 계층은 전체 시스템에서 가장 중요한 위치를 차지하며, 시스템의 모든 연산 과정을 담당하고 어떤 종류의 애플리케이션을 실행할 수 있는지를 결정한다.

무한한 가능성의 실행 환경

이론적으로 실행 계층의 실행 환경은 어떤 형태로든 구성될 수 있으며, 가능성은 무한하다. 구체적인 형태는 프로젝트 팀의 목표 설정에 따라 달라진다:

거래소: SCP를 기반으로 공개적이고 투명하며 고속 TPS를 지닌 거래소를 구축할 수 있다. 이 거래소는 CEX처럼 빠르고 0비용의 특성을 가지면서도 DEX의 탈중앙화를 유지할 수 있다. 여기서 CEX와 DEX의 경계는 모호해진다.
결제 네트워크: 알리페이, 페이팔(PayPal)과 유사한 형태.
프로그램/컨트랙트 로딩을 지원하는 가상 머신 또는 블록체인: 임의의 개발자가 자신의 애플리케이션을 배포할 수 있으며, 다른 프로그램들과 모든 사용자 데이터를 공유하고 사용자 지시에 따라 동작한다.

SCP가 임의의 실행 환경을 지원하는 설계 방식은 독특한 장점을 지닌다: 역사적 부담을 지닌 특정 구성 요소(예: 이더리움 커뮤니티가 고안한 '계정 추상화(account abstraction)' 개념)에 더 이상 의존할 필요가 없다. SCP는 이러한 개념을 본질적으로 필요로 하지 않는다.

SCP 아키텍처에서는 아예 계정 추상화라는 개념 자체가 존재하지 않는다 — Web2 표준 계정이나 블록체인 계정을 자유롭게 선택할 수 있다. 이 관점에서 보면, 많은 성숙한 Web2 애플리케이션 사례들은 다시 고민하거나 재구성할 필요 없이 그대로 SCP에 적용될 수 있다. 이는 SCP가 롤업 대비 가지는 이점 중 하나일지도 모른다.

투명성과 비대칭성

앞서 계정 시스템에 대해 언급했는데, 민감한 독자라면 이미 눈치챘겠지만, SCP는 Web2 계정 체계를 활용할 수는 있어도 그대로 사용하는 것은 문제가 있다.

왜냐하면 이 전체 시스템은 완전히 투명하기 때문이다! 사용자와 서버 간의 상호작용 모델을 그대로 적용하면 심각한 문제가 발생하며, 시스템 전반의 보안이 무너질 수 있다. 먼저 전통적인 서버-사용자 모델이 어떻게 작동하는지 복습해보자:

1. 계정 등록: 사용자가 애플리케이션의 등록 페이지에서 사용자 이름과 비밀번호를 입력한다. 비밀번호 보호를 위해 서버는 수신 후 해시 함수를 사용해 비밀번호를 처리한다. 해시의 복잡성을 높이고 레인보우 테이블 공격을 방지하기 위해 각 사용자의 비밀번호에 임의의 문자열(이른바 '솔트(salt)')을 붙여 함께 해싱한다. 사용자 이름, 솔트, 해시값은 서비스 제공자의 데이터베이스에 평문으로 저장되며 외부에 공개되지 않는다. 하지만 그래도 솔트 추가 및 보안 처리가 필요하다. 내부자 방지와 외부 공격 방어를 위해서이다.

2. 사용자 로그인: 사용자가 로그인 폼에 사용자 이름과 비밀번호를 입력한다. 시스템은 처리된 비밀번호 해시값과 데이터베이스에 저장된 해시값을 비교한다. 두 값이 일치하면 올바른 비밀번호 입력을 확인하고 로그인 과정을 진행한다.

3. 작업 인증: 로그인 인증이 완료되면 시스템은 사용자를 위한 세션을 생성한다. 일반적으로 세션 정보는 서버에 저장되며, 서버는 식별자(cookie 또는 token)를 사용자의 브라우저나 앱에 전송한다. 이후 사용자는 사용자 이름과 비밀번호를 반복 입력할 필요 없이 브라우저나 앱이 cookie 식별자를 저장하고 각 요청에 포함시켜 자신이 해당 서버의 허가를 받았음을 증명한다.

다음으로 전형적인 Web3 블록체인-사용자 상호작용 체계를 복습하자:

1. 계정 등록: 사실상 계정 등록 과정이 없으며, 사용자 이름-비밀번호 체계도 존재하지 않는다. 계정(주소)은 등록할 필요 없이 자연스럽게 존재하며, 누구나 해당 개인키를 소유하면 계정을 제어할 수 있다. 개인키는 지갑이 로컬에서 무작위로 생성하며, 네트워크 연결이 필요 없다.

2. 사용자 로그인: 블록체인 사용에는 로그인이 필요하지 않으며, 대부분의 dApp은 로그인 과정 없이 지갑 연결만 한다. 일부 dApp은 지갑 연결 후 사용자에게 서명 검증을 요청해, 사용자가 단지 프론트엔드에 주소를 전달한 것이 아니라 실제로 개인키를 소유하고 있음을 확인한다.

3. 작업 인증: 사용자가 직접 노드에 서명된 데이터를 제출하면, 노드는 검증 후 블록체인 네트워크 전체에 거래를 브로드캐스트하고, 네트워크 컨센서스를 만족하면 사용자의 작업이 확정된다.

두 모델의 차이는 대칭성과 비대칭성에서 비롯된다. 서버-사용자 아키텍처에서는 양측이 동일한 비밀을 공유한다. 반면 블록체인-사용자 아키텍처에서는 사용자만이 비밀을 소유한다.

SCP의 실행 계층은 블록체인이 아닐 수 있지만, 모든 데이터는 공개적으로 확인 가능한 DA 계층에 동기화되어야 한다. 따라서 SCP가 사용하는 로그인 및 작업 검증 방식은 반드시 비대칭적이어야 한다. 그러나 대규모 채택을 저해하는 개인키 보관, 지갑 사용 등의 번거로운 절차와 열악한 UX를 피하고자 하므로, SCP 기반 애플리케이션은 기존 ID-비밀번호 또는 OAuth 제3자 인증 로그인에 대한 강한 수요를 가진다. 그렇다면 이 둘을 어떻게 결합할 수 있을까?

비대칭 암호학과 제로노울리지 증명(ZKP)이 비대칭성을 제공한다는 점에서, 두 가지 가능한 방안을 제안한다:

ID-비밀번호 체계를 사용하고자 할 경우, 비밀번호 저장 모듈을 SCP 내부에 포함시키지 않고 외부에 두어 다른 사람들의 접근을 차단할 수 있다. SCP 실행 계층 내부는 여전히 블록체인의 공개키/개인키 기반 계정 및 운영 로직을 사용하며, 등록이나 로그인 과정이 없다. 사용자의 ID는 실제로 하나의 개인키에 대응한다. 이 개인키는 프로젝트 팀이 보관해서는 안 되며, 중심화 저장 문제를 해결하기 위해 2-3 MPC를 사용하는 것이 현실적인 방법이다. 동시에 사용자가 개인키를 직접 관리하는 번거로움은 피할 수 있다.
OAuth 로그인을 의존할 경우 JWT(Json Web Token)를 신원 인증 수단으로 활용할 수 있다. 이 방법은 앞선 방식보다 다소 중심화되어 보일 수 있는데, 본질적으로 Web2 대기업이 제공하는 제3자 로그인 서비스에 신원 인증을 의존해야 하기 때문이다.

최초로 제3자 로그인을 사용할 때, JWT 내 사용자 신원 및 서비스 제공자 신원 필드를 시스템 내부에 등록한다. 이후 사용자의 작업에서, 작업 명령을 public input으로, JWT 전체를 secret witness로 하여 ZKP로 각 거래를 검증한다.
각 JWT는 만료 기한이 있으며, 다음 로그인 시 새 JWT를 발급받으므로 영구 보관이 필요 없다. 또한 시스템 내부에서는 JWK(공개키 집합)도 필요하며, 이는 대기업이 JWK 검증을 위한 공개키를 제공한다고 이해할 수 있다. JWK를 어떻게 탈중앙화 방식으로 시스템에 입력할 것인지, 향후 개인키 회전에 대응하는 방법 등도 향후 논의할 가치가 있다.

어느 방식을 사용하든 전통적인 방식보다 개발 및 연산 비용이 다소 높아지지만, 이는 탈중앙화를 위해 감수해야 하는 필수적 비용이다. 물론 프로젝트 팀이 극도의 탈중앙화가 필수적이지 않다고 판단하거나, 개발 단계마다 다른 마일스톤을 설정한다면 이러한 설계를 생략할 수도 있다. 탈중앙화는 흑백 논리가 아니라 회색 지대가 존재하기 때문이다.

프라이버시

앞서 언급한 투명성 문제는 사용자 상호작용 패턴뿐 아니라 사용자 데이터에도 영향을 준다. 사용자 데이터가 모두 노출되기 때문이다. 블록체인에서는 문제가 되지 않지만, 일부 애플리케이션에서는 수용하기 어렵다. 따라서 개발자는 프라이버시 거래 시스템을 별도로 구축할 수도 있다.

요금

실행 계층의 요금 부과 방식도 주목할 만한 요소다. DA 계층에 데이터를 제출하는 데 비용이 들며, 자체 서버 운영 비용도 발생하기 때문이다. 전통적인 블록체인에서 가스비를 부과하는 핵심 목적 중 하나는 사용자가 반복적인 거래를 대량으로 보내 거래 네트워크를 파괴하는 것을 막기 위함이며, 두 번째는 가스를 기준으로 거래 우선순위를 정하기 위함이다. Web2에는 이런 우려가 없으므로 홍수 공격(flood), DDoS 등의 기본 개념만 존재한다.

실행 계층은 완전 무료 또는 부분 유료 등 다양한 요금 전략을 자체적으로 정할 수 있으며, MEV(정렬기에서 이미 매우 성숙함), 마케팅 활동 등을 통해 수익을 창출할 수도 있다.

검열 저항성

실행 계층은 검열 저항성을 갖추지 못しており, 이론적으로 사용자의 거래를 무제한으로 거부할 수 있다. 롤업에서는 L1 컨트랙트의 강제 제출 기능으로 검열 저항성을 보장할 수 있고, 사이드체인이나 공용 블록체인은 완전한 분산 네트워크이므로 검열이 어렵다.

현재로서는 검열 저항 문제를 해결할 명확한 방안이 없으며, 이는 SCP 패러다임의 한계점이다.

컨센서스 계층

이 계층은 느슨하게 연결된 노드들로 구성되며, 노드들이 자발적으로 네트워크를 형성하지 않기 때문에 엄밀한 의미의 컨센서스 계층이라기보다는, 외부(예: 사용자)에게 현재 실행 계층의 상태를 확인시켜주는 역할을 한다.

예를 들어, 이러한 노드들의 운용 상태에 의문을 가진다면 디텍터 클라이언트를 다운로드해 설치할 수 있다. 이 클라이언트는 코디네이터와 동일한 프로그램 코드를 실행한다.

하지만 롤업과 유사하게 데이터가 일괄 제출되기 때문에, 실행 계층이 사용자에게 반환하는 상태는 항상 DA 계층보다 앞선다. 여기서 '사전 확정(pre-confirmation)' 문제가 발생한다:

실행 계층이 사용자에게 제공하는 것은 사전 확정, 즉 소프트 최종성(soft finality)의 결과다. 아직 DA 계층에 제출되지 않았기 때문이다.

반면 컨센서스 계층이 사용자에게 제공하는 것은 하드 최종성(hard finality)이다. 사용자 입장에서는 크게 중요하지 않을 수 있으나, 크로스체인 브릿지 등의 애플리케이션에서는 반드시 하드 최종성을 따라야 한다. 예를 들어 거래소의 입출금 시스템은 롤업 정렬기가 체인 외부에서 브로드캐스트한 데이터를 신뢰하지 않으며, 해당 데이터가 이더리움에 올라온 후에야 인정한다.

결과 확인 외에도 컨센서스 계층의 또 하나 중요한 역할은 실행 계층의 재해 복구용 중복 기능이다. 실행 계층이 영구적으로 중단되거나 심각한 악행을 저지를 경우, 이론적으로 모든 컨센서스 계층 노드가 실행 계층의 작업을 인수하여 사용자의 요청을 수신할 수 있다. 이렇게 심각한 상황이 발생하면 커뮤니티는 안정적이고 신뢰할 수 있는 노드를 선정하여 실행 계층 서버로 삼을 것이다.

정산 계층

SCP는 롤업이 아니기 때문에, 롤업처럼 인공 개입 없이 암호학과 스마트 컨트랙트 코드에 기반한 완전한 트러스트리스 출금 기능을 제공할 수 없다. SCP 크로스체인 브릿지의 보안 수준은 사이드체인이나 제3자 증인 기반 브릿지와 동일하며, 권한을 가진 멀티시그 관리자들이 자산 출금을 승인해야 하므로 '증인 모드(witness model)'라고 부른다.