기술 스택 확장: zkTLS의 원리 및 잠재적 활용 사례 개요
작성자:@Web3_Mario
요약: 최근 새로운 프로젝트 방향을 모색하면서 제품 설계 과정에서 이전에 접해보지 못한 기술 스택을 마주하게 되어 이를 연구하고 학습 내용을 정리하여 여러분과 공유하고자 한다.
전반적으로 zkTLS는 제로 나이 지식 증명(ZKP)과 TLS(전송 계층 보안 프로토콜)을 결합한 새로운 유형의 기술로, Web3 분야에서 주로 체인 상 가상 머신 환경에서 제3자 신뢰 없이 제공되는 오프체인 HTTPS 데이터의 진위를 검증하는 데 사용된다. 여기서 말하는 진위성은 세 가지 측면을 포함한다. 즉, 데이터 소스가 특정 HTTPS 자원에서 실제로 유래했는지, 반환된 데이터가 조작되지 않았는지, 데이터의 실시간성이 보장될 수 있는지를 의미한다.
이러한 암호학적 구현 메커니즘을 통해 체인 상 스마트 계약이 신뢰할 수 있는 방식으로 오프체인 Web2 HTTPS 자원에 접근할 수 있게 되며, 정보 아일랜드 문제를 해결할 수 있다.
TLS 프로토콜이란 무엇인가?
zkTLS 기술의 가치를 깊이 이해하기 위해 TLS 프로토콜에 대해 간략히 개관할 필요가 있다. 우선 TLS(전송 계층 보안 프로토콜)는 네트워크 통신 중 암호화, 인증, 데이터 무결성을 제공하여 클라이언트(예: 브라우저)와 서버(예: 웹사이트) 간 데이터 안전 전송을 보장한다. 웹 개발 외 분야의 사용자들은 웹사이트 방문 시 일부 도메인이 https 접두사를 사용하고 다른 일부는 http 접두사를 사용하는 것을 알 수 있다. 후자의 경우 주류 브라우저는 일반적으로 '안전하지 않음'을 경고하며, 전자의 경우 "연결이 비공개 연결이 아닙니다" 또는 HTTPS 인증서 오류 등의 경고를 자주 만나게 된다. 이러한 경고의 원인은 바로 TLS 프로토콜의 유효성 여부에 있다.
구체적으로 설명하자면,所谓 HTTPS 프로토콜은 HTTP 프로토콜 위에 TLS 프로토콜을 활용하여 정보 전송의 사생활 보호 및 무결성을 보장하며, 서버 측의 진위성을 검증 가능하게 만든다. 우리는 HTTP 프로토콜이 평문 전송 방식의 네트워크 프로토콜이며, 서버 측 진위성을 검증할 수 없다는 점을 알고 있다. 이로 인해 다음과 같은 몇 가지 보안 문제가 발생한다:
1. 클라이언트와 서버 간 전송되는 정보가 제3자에 의해 엿볼릴 수 있어 개인정보 유출이 발생할 수 있다;
2. 서버 측의 진위성을 검증할 수 없으므로 요청이 악의적인 노드에 의해 가로채여 악성 정보가 반환될 수 있다;
3. 반환되는 정보의 무결성을 검증할 수 없으므로 네트워크 상의 이유로 데이터 손실이 발생할 수도 있다;
TLS 프로토콜은 바로 이러한 문제들을 해결하기 위해 설계되었다. 참고로 일부 사용자는 SSL 프로토콜을 알고 있을 수 있는데, 사실상 TLS 프로토콜은 SSL 3.1 버전을 기반으로 개발되었으며 단지 상업적 이유로 이름만 변경된 것이며, 본질적으로 동일한 계보를 따른다. 따라서 일부 맥락에서는 두 용어를 서로 교환하여 사용하기도 한다.
TLS 프로토콜이 위 문제들을 해결하는 주요 아이디어는 다음과 같다:
1. 암호화 통신: 대칭 암호화(AES, ChaCha20)를 사용하여 데이터를 보호하고 도청을 방지한다.
2. 신분 인증: 제3자가 특정 기관에 발급한 디지털 인증서(X.509 인증서 등)를 통해 서버의 신분을 검증함으로써 중간자 공격(MITM)을 방지한다.
3. 데이터 무결성: HMAC(해시 메시지 인증 코드) 또는 AEAD(인증 암호화)를 사용하여 데이터가 조작되지 않았음을 보장한다.
이제 TLS 프로토콜 기반의 HTTPS 프로토콜이 데이터 상호 작용 과정에서의 기술적 세부사항을 간단히 설명하겠다. 전체 과정은 크게 두 단계로 나뉜다. 먼저 핸드셰이크 단계(Handshake)로, 클라이언트와 서버가 보안 파라미터를 협의하고 암호화 세션을 설정한다. 다음은 데이터 전송 단계로, 세션 키를 사용하여 암호화 통신을 수행한다. 구체적인 과정은 총 네 단계로 구성된다:
1. 클라이언트가 ClientHello 전송:
클라이언트(예: 브라우저)가 서버에 ClientHello 메시지를 보내며, 그 내용은 다음과 같다:
l 지원하는 TLS 버전(예: TLS 1.3)
l 지원하는 암호화 알고리즘(Cipher Suites, 예: AES-GCM, ChaCha20)
l 난수(Client Random)(키 생성용)
l 키 공유 파라미터(예: ECDHE 공개키)
l SNI(서버 이름 지시)(옵션, 다중 도메인 HTTPS 지원용)
목적은 서버가 클라이언트의 암호화 능력을 인지하고 보안 파라미터를 준비하게 하는 것이다.
2. 서버가 ServerHello 전송:
서버가 ServerHello 메시지로 응답하며, 그 내용은 다음과 같다:
l 선택된 암호화 알고리즘
l 서버 난수(Server Random)
l 서버 인증서(X.509 인증서)
l 서버의 키 공유 파라미터(예: ECDHE 공개키)
l Finished 메시지(핸드셰이크 완료 확인용)
목적은 클라이언트가 서버의 신분을 인지하고 보안 파라미터를 확인하게 하는 것이다.
3. 클라이언트가 서버 검증:
클라이언트는 다음 작업을 수행한다:
l 서버 인증서 검증: 인증서가 신뢰할 수 있는 CA(인증 기관)에 의해 발급되었는지 확인하고, 인증서가 만료되었거나 폐기되었는지 검사한다;
l 공유 키 계산: 자신의 ECDHE 공개키와 서버의 ECDHE 공개키를 사용하여 세션 키(Session Key)를 계산한다. 이 키는 이후 통신의 대칭 암호화(예: AES-GCM)에 사용된다.
l Finished 메시지 전송: 핸드셰이크 데이터 무결성을 입증하여 중간자 공격(MITM)을 방지한다.
목적은 서버의 신뢰성을 확보하고 세션 키를 생성하는 것이다.
4. 암호화 통신 시작:
클라이언트와 서버는 이제 협의된 세션 키를 사용하여 암호화 통신을 수행한다.
l 대칭 암호화(예: AES-GCM, ChaCha20)를 사용하여 데이터를 암호화하여 속도와 보안성을 높인다.
l 데이터 무결성 보호: AEAD(예: AES-GCM)를 사용하여 조작을 방지한다.
따라서 이 네 단계를 거치면 HTTP 프로토콜의 문제를 효과적으로 해결할 수 있다. 그러나 Web2 네트워크에서 광범위하게 사용되는 이 기초 기술은 Web3 애플리케이션 개발에 어려움을 초래한다. 특히 체인 상 스마트 계약이 오프체인 데이터에 접근하려 할 때, 데이터 가용성 문제로 인해 체인 상 VM은 외부 데이터 호출 기능을 개방하지 않는다. 이는 모든 데이터의 추적 가능성을 보장하고, 결과적으로 합의 메커니즘의 보안성을 유지하기 위한 것이다.
그러나 일련의 반복 개선 후 개발자들은 DApp이 여전히 오프체인 데이터에 대한 수요가 있음을 발견하였고, 이에 따라 Chainlink, Pyth 등의 오라클(Oracle) 프로젝트들이 등장하였다. 이들은 체인 상과 체인 하 데이터 사이의 리레이 브릿지 역할을 수행하여 정보 아일랜드 현상을 해소한다. 동시에 리레이 데이터의 가용성을 보장하기 위해 이러한 오라클은 일반적으로 PoS 합의 메커니즘을 통해 운영되며, 리레이 노드가 악행을 저지를 비용이 수익보다 크도록 만들어 경제적 관점에서 체인 상에 잘못된 정보를 제공하지 않도록 한다. 예를 들어 스마트 계약 내에서 Binance, Coinbase 등의 중심화 거래소에서 BTC의 가중 평균 가격을 조회하고자 할 경우, 이러한 오라클을 통해 오프체인에서 데이터를 수집하여 집계한 후 체인 상 스마트 계약에 저장해야만 사용할 수 있다.
zkTLS가 해결하는 문제는 무엇인가?
그러나 사람들은 오라클 기반의 데이터 취득 방식이 두 가지 문제점을 가지고 있음을 발견하였다:
1. 비용이 너무 높음: 오라클이 체인 상에 전달하는 데이터가 조작되지 않은 진짜 데이터임을 보장하기 위해서는 PoS 합의 메커니즘이 필요하다는 점을 알고 있다. 그러나 PoS 합의 메커니즘의 보안성은 스테이킹 금액에 기반하므로 운영 비용이 발생한다. 게다가 일반적으로 PoS 합의 메커니즘에서는 많은 양의 데이터 중복 전송, 계산, 집계가 이루어져야 합의를 달성할 수 있으므로 데이터 사용 비용이 더욱 증가한다. 따라서 오라클 프로젝트들은 고객 유치를 위해 대부분 무료로 가장 주류인 데이터(BTC 등 주요 자산 가격 등)만 제공하며, 특화된 요구사항의 경우 별도 요금을 지불해야 한다. 이는 특히 장티(LT) 혹은 맞춤형 수요와 같은 애플리케이션 혁신을 저해한다.
2. 효율이 너무 낮음: 일반적으로 PoS 메커니즘의 합의에는 일정한 시간이 소요되므로 체인 상 데이터의 지연성이 발생하며, 이는 고빈도 액세스 사용 시나리오에 불리하다. 왜냐하면 체인 상에서 획득한 데이터와 실제 오프체인 데이터 사이에 상당한 지연이 존재하기 때문이다.
이러한 문제들을 해결하기 위해 zkTLS 기술이 등장하였다. 그 핵심 아이디어는 ZKP 제로 나이 지식 증명 알고리즘을 도입하여 체인 상 스마트 계약이 제3자로서 어떤 노드가 제공한 데이터가 특정 HTTPS 자원에 접속한 후 반환된 데이터임을 직접 검증할 수 있도록 하고, 데이터가 조작되지 않았음을 보장함으로써, 기존 오라클이 합의 알고리즘으로 인해 발생하는 높은 사용 비용을 피하는 것이다.
일부 사용자는 왜 체인 상 VM 환경에 Web2 API 호출 기능을 직접 내장하지 않는지 질문할 수 있다. 답은 '불가능하다'이다. 체인 상 환경이 폐쇄적인 데이터 구조를 유지해야 하는 이유는 모든 데이터의 추적 가능성을 보장하기 위해서이다. 즉 합의 과정에서 모든 노드가 특정 데이터 혹은 실행 결과의 정확성에 대해 동일한 평가 로직, 즉 객관적인 검증 로직을 갖도록 해야 한다. 이를 통해 완전히 신뢰하지 않는 환경에서도 대부분의 선의를 가진 노드들이 자신들의 중복 데이터 판단을 바탕으로 직접 결과의 진위를 판단할 수 있다. 그러나 Web2 데이터의 경우 그러한 통일된 평가 로직을 구성하기 어렵다. 왜냐하면 일부 네트워크 지연 등의 이유로 서로 다른 노드가 동일한 Web2 HTTPS 자원에 접속했을 때 서로 다른 결과를 얻을 수 있기 때문에 합의에 어려움을 초래하며, 특히 고빈도 데이터 분야에서 더욱 그렇다. 게다가 다른 중요한 문제는 HTTPS 프로토콜이 의존하는 TLS 프로토콜의 보안성이 클라이언트가 생성한 난수(Client Random)(키 생성용) 및 키 공유 파라미터에 의존하여 서버와 암호화 키 협상을 수행한다는 점이다. 하지만 체인 상 환경은 공개적이므로 스마트 계약이 난수와 키 공유 파라미터를 관리한다면 핵심 데이터가 노출되어 데이터 사생활이 침해될 수 있다.
이에 반해 zkTLS는 다른 방법을 채택하는데, 암호학적 보호를 통해 기존 오라클이 합의 메커니즘에 의존하여 데이터 가용성을 확보하는 데 드는 높은 비용을 대체하는 것이다. 마치 L2에서 ZK-Rollup이 OP-Rollup을 최적화하는 것과 유사하다. 구체적으로 말하면 ZKP 제로 나이 지식 증명을 도입하여 오프체인 리레이 노드가 특정 HTTPS로부터 얻은 자원, 관련 CA 인증서 검증 정보, 시퀀싱 증명, 그리고 HMAC 또는 AEAD 기반의 데이터 무결성 증명 등을 계산하여 Proof를 생성하고, 체인 상에서는 필요한 검증 정보와 검증 알고리즘을 유지함으로써 스마트 계약이 핵심 정보를 노출하지 않으면서도 데이터의 진위성, 실시간성, 데이터 소스의 신뢰성을 검증할 수 있도록 한다. 구체적인 알고리즘 세부사항은 여기서 논의하지 않으며 관심 있는 사용자는 추가 연구를 권장한다.
이 기술 방식의 가장 큰 장점은 Web2 HTTPS 자원의 가용성을 확보하는 비용을 낮추는 것이다. 이는 장티 자산의 체인 상 가격 획득 비용 감소, Web2 세계의 권위 있는 웹사이트를 활용한 체인 상 KYC, DID 최적화, Web3 Game의 기술 아키텍처 설계 등 다양한 신규 수요를 촉진한다. 물론 zkTLS가 기존 Web3 기업에 미치는 충격도 존재하며, 특히 현재 주류인 오라클 프로젝트들에 영향을 준다. 따라서 이러한 충격에 대응하기 위해 Chainlink, Pyth 등 해당 분야의 거대 기업들은 관련 연구를 적극적으로 진행하며 기술 반복 과정에서도 주도권을 유지하려 하고 있으며, 이는 새로운 비즈니스 모델(예: 기존의 시간 기반 요금제에서 사용량 기반 요금제로의 전환, Compute as a Service 등)의 출현도 유도할 것이다. 물론 여기서의 난제는 대부분의 ZK 프로젝트들과 마찬가지로 계산 비용을 얼마나 낮출 수 있느냐, 즉 상업적 가치를 부여할 수 있느냐에 있다.
종합하면, 제품 설계 시 여러분도 zkTLS의 발전 동향에 주목하고 적절한 부분에서 이 기술 스택을 통합함으로써 사업 혁신 및 기술 아키텍처 측면에서 새로운 방향을 찾을 수 있을 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@web3_mario
