기술 스택 확장: 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 메시지를 전송하며, 내용은 다음과 같습니다:

• 지원하는 TLS 버전(예: TLS 1.3)
• 지원하는 암호화 알고리즘(Cipher Suites, 예: AES-GCM, ChaCha20)
• 난수(Client Random)(키 생성에 사용)
• 키 공유 매개변수(예: ECDHE 공개 키)
• SNI(서버 이름 표시)(선택 사항, 다중 도메인 HTTPS 지원용)

목적은 서버가 클라이언트의 암호화 능력을 알고 보안 매개변수를 준비하는 것입니다.

2. 서버가 ServerHello를 전송합니다:

서버는 ServerHello 메시지로 응답하며, 내용은 다음과 같습니다:

• 선택된 암호화 알고리즘
• 서버 난수(Server Random)
• 서버의 인증서(X.509 인증서)
• 서버의 키 공유 매개변수(예: ECDHE 공개 키)
• Finished 메시지(핸드쉐이크 완료 확인용)

목적은 클라이언트가 서버의 신원을 알고 보안 매개변수를 확인하는 것입니다.

3. 클라이언트가 서버를 검증합니다:

클라이언트는 다음 작업을 수행합니다:

• 서버 인증서 검증: 인증서가 신뢰할 수 있는 CA(인증 기관)에 의해 발급되었는지 확인하고, 인증서가 만료되었거나 취소되지 않았는지 검증합니다;
• 공유 키 계산: 자신과 서버의 ECDHE 공개 키를 사용하여 세션 키(Session Key)를 계산합니다. 이 키는 후속 통신의 대칭 암호화(예: AES-GCM)에 사용됩니다.
• Finished 메시지 전송: 핸드쉐이크 데이터의 무결성을 증명하여 중간자 공격(MITM)을 방지합니다.

목적은 서버가 신뢰할 수 있음을 보장하고 세션 키를 생성하는 것입니다.

4. 암호화 통신 시작:

클라이언트와 서버는 이제 협상된 세션 키를 사용하여 암호화 통신을 수행합니다.

• 대칭 암호화(예: AES-GCM, ChaCha20)를 사용하여 데이터를 암호화하여 속도와 보안을 높입니다.
• 데이터 무결성 보호: AEAD(예: AES-GCM)를 사용하여 변조를 방지합니다.

따라서 이 네 단계의 작업을 통해 HTTP 프로토콜의 문제를 효과적으로 해결할 수 있습니다. 그러나 Web2 네트워크에서 광범위하게 사용되는 이 기본 기술은 Web3 애플리케이션 개발에 어려움을 초래했습니다. 특히 체인 상의 스마트 계약이 특정 오프체인 데이터에 접근하고자 할 때, 데이터 가용성 문제로 인해 체인 상의 가상 머신은 외부 데이터 호출 능력을 개방하지 않으며, 모든 데이터의 추적 가능성을 보장하여 합의 메커니즘의 안전성을 확보합니다.

그러나 일련의 반복 과정을 거치면서 개발자들은 DApp이 체인 외 데이터에 대한 필요가 있음을 발견하였고, 이에 따라 Chainlink, Pyth와 같은 일련의 오라클 프로젝트가 등장했습니다. 이들은 체인 상의 데이터와 체인 외 데이터를 중계하는 역할을 하여 데이터 고립 현상을 깨뜨립니다. 또한 중계 데이터의 가용성을 보장하기 위해 이러한 오라클은 일반적으로 PoS 합의 메커니즘을 통해 구현합니다. 즉, 중계 노드의 악의적 행동 비용이 수익보다 높아야 하며, 경제적 효익 측면에서 체인 상에 잘못된 정보를 제공하지 않도록 합니다. 예를 들어, 우리는 스마트 계약에서 Binance, Coinbase와 같은 중앙화 거래소의 BTC 가중 가격에 접근하고자 할 때, 이러한 오라클을 통해 데이터를 오프체인에서 접근하고 집계하여 체인 상의 스마트 계약에 저장해야 사용할 수 있습니다.

zkTLS는 어떤 문제를 해결했는가

그러나 사람들은 이러한 오라클 기반 데이터 획득 방식이 두 가지 문제를 가지고 있음을 발견했습니다:

1. 비용이 과다함: 우리는 오라클이 체인 상에 전달하는 데이터가 진짜 데이터이며 변조되지 않았음을 보장하기 위해 PoS 합의 메커니즘이 필요하다는 것을 알고 있습니다. 그러나 PoS 합의 메커니즘의 안전성은 스테이킹 자금의 양에 기반하고 있어 유지 관리에 비용이 발생합니다. 또한 일반적으로 PoS 합의 메커니즘에는 많은 데이터 상호작용의 중복이 존재합니다. 데이터 집합이 네트워크에서 대량으로 반복 전송, 계산, 집계되어야 합의가 이루어지기 때문에 데이터 사용 비용이 증가합니다. 따라서 일반적으로 오라클 프로젝트는 고객을 유치하기 위해 가장 주류 데이터(예: BTC 등)의 가격만 무료로 유지합니다. 특정 요구 사항에 대해서는 비용을 지불해야 합니다. 이는 애플리케이션 혁신을 저해하며, 특히 긴 꼬리, 맞춤형 요구 사항에 대해 그렇습니다.

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 게임의 기술 아키텍처 설계를 최적화하는 등의 측면에서 그렇습니다. 물론 우리는 zkTLS가 기존 Web3 기업에 미치는 충격도 존재한다는 것을 알 수 있습니다. 특히 현재 주류 오라클 프로젝트에 대해 그렇습니다. 따라서 이러한 충격에 대응하기 위해 Chainlink, Pyth와 같은 업계 거대 기업들은 관련 방향의 연구를 적극적으로 진행하여 기술 진화 과정에서도 여전히 주도권을 유지하려고 하며, 새로운 비즈니스 모델을 촉발할 것입니다. 예를 들어, 원래 시간당 요금에서 사용량 기반 요금으로 전환하거나 Compute as a service와 같은 모델로 전환하는 것입니다. 물론 여기서의 난점은 대부분의 ZK 프로젝트와 마찬가지로 계산 비용을 어떻게 낮추어 상업적 가치를 갖게 할 것인가입니다.

종합적으로 볼 때, 친구들이 제품 디자인을 할 때 zkTLS의 발전 동향에 주목하고 적절한 분야에서 이 기술 스택을 통합하면 비즈니스 혁신 및 기술 아키텍처 측면에서 새로운 방향을 찾을 수 있을 것입니다.