저자: @Web3_Mario
Abstract: 최근 프로젝트의 새로운 방향을 모색하던 중 제품 디자인 작업을 하면서 이전에 접해보지 못했던 기술 스택을 접하게 되어 조금 조사하고 배운 내용을 정리하여 여러분과 공유하고자 합니다. 간단히 설명하자면, zkTLS는 웹3.0 트랙에서 주로 사용되는 영지식증명(ZKP)과 전송 계층 보안 프로토콜(TLS)을 결합한 새로운 기술로 제3자를 신뢰하지 않고 오프체인 VM이 제공하는 HTTPS 데이터의 진위를 검증하는데, 진위는 데이터의 출처가 정말 특정 HTTPS 자원에서 나온 것인지, 리턴된 데이터가 인증되지 않았는지, HTTPS 자원에서 데이터를 반환하지 않았는지 세 가지 측면으로 구성돼 있습니다. 여기서 진위성은 데이터 소스가 HTTPS 리소스에서 비롯되고, 반환된 데이터가 변조되지 않았으며, 데이터의 유효성을 보장할 수 있다는 세 가지 측면으로 구성됩니다. 이러한 암호화 구현 메커니즘을 통해 온체인 스마트 콘트랙트는 오프체인 웹2.0 HTTPS 리소스에 신뢰성 있게 접근할 수 있는 기능을 확보하여 데이터 사일로를 깨뜨릴 수 있습니다.
TLS 프로토콜이란
zkTLS 기술의 가치를 보다 심도 있게 이해하기 위해서는 TLS 프로토콜에 대한 간략한 개요가 필요합니다. 먼저 TLS(전송 계층 보안 프로토콜)는 클라이언트(예: 브라우저)와 서버(예: 웹사이트) 간의 안전한 데이터 전송을 보장하기 위해 네트워크 통신에서 암호화, 인증 및 데이터 무결성을 제공하는 데 사용됩니다. 웹 개발 방향이 아닌 파트너의 경우 웹사이트에 액세스할 때 일부 도메인의 접두사는 https로, 일부 도메인의 접두사는 http로 시작하는 것을 볼 수 있습니다. 후자에 액세스하면 주류 브라우저는 안전하지 않다고 표시합니다. 전자의 경우 "귀하의 링크는 비공개 링크가 아닙니다" 또는 HTTPS 인증서 오류 메시지가 나타나기 쉽습니다. 그 이유는 TLS 프로토콜을 사용할 수 없기 때문입니다.
특히, 소위 HTTPS 프로토콜은 정보 전송의 개인 정보 보호 및 무결성을 보장하고 서버 측의 진위 여부를 서버 측이 검증 할 수 있도록하기 위해 TLS 프로토콜의 사용을 기반으로하는 HTTP 프로토콜입니다. 아시다시피 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)
지원되는 암호화 알고리즘(암호 모음, 예: AES-GCM, ChaCha20)
클라이언트 무작위(키 생성용)
키 공유 매개변수(예: ECDHE 공개 키)
SNI(서버 이름 표시)(선택 사항, 다중 도메인 HTTPS 지원 시 사용)
이 기능은 서버에 클라이언트의 암호화 기능을 알리고 보안 매개변수를 준비하기 위한 것입니다.
2. 서버가 ServerHello를 전송합니다:
서버는 다음을 포함하는 ServerHello 메시지로 응답합니다.
목적은 클라이언트에 서버의 신원을 알리고 보안 매개변수를 확인하는 것입니다.
3. 클라이언트가 서버를 인증합니다:
클라이언트는 다음을 수행합니다:
서버 인증서 확인: 신뢰할 수 있는 CA(인증 기관)에서 발급한 인증서인지 확인하고 인증서가 만료되거나 해지되지 않았는지 확인합니다.
공유 키 계산: 후속 통신의 대칭 암호화에 사용되는 자체 및 서버의 ECDHE 공개키를 사용하여 세션 키를 계산합니다(예: AES-GCM). 후속 통신을 위한 대칭 암호화(예: AES-GCM)에 사용됩니다.
완료 메시지 보내기: 중간자 공격(MITM)을 방지하기 위해 핸드셰이크 데이터의 무결성을 증명합니다.
서버를 신뢰할 수 있는지 확인하고 세션 키를 생성하는 것이 목적입니다.
4. 암호화된 통신 시작:
이제 클라이언트와 서버가 협상된 세션 키를 사용하여 암호화된 통신을 합니다.
속도 및 보안 향상을 위해 대칭 암호화(예: AES-GCM, ChaCha20)를 사용하여 데이터를 암호화합니다.
데이터 무결성 보호: AEAD(예: AES-GCM)로 데이터 변조를 방지합니다.
이 네 단계를 거치면 HTTP 프로토콜은 효과적으로 해결될 수 있습니다. 그러나 웹2 네트워크에서 널리 사용되는 이 기본 기술은 웹3 애플리케이션 개발, 특히 온체인 스마트 컨트랙트가 특정 오프체인 데이터에 액세스하고자 할 때 데이터 가용성 문제로 인해 온체인 가상 머신이 모든 데이터를 추적하여 합의 메커니즘의 보안을 보장하기 위해 외부 데이터를 요청할 수 없는 문제를 야기했습니다.
그러나 일련의 반복 끝에 개발자들은 디앱에 여전히 오프체인 데이터가 필요하다는 것을 알게 되었고, 체인링크와 파이스 같은 일련의 예언 머신 오라클 프로젝트가 등장했습니다. 이들은 온체인 데이터와 오프체인 데이터 사이의 중계 다리 역할을 함으로써 이러한 데이터 사일로 현상을 깨뜨립니다. 동시에, 이러한 오라클은 릴레이 데이터의 가용성을 보장하기 위해 일반적으로 지분 증명 합의 메커니즘, 즉 릴레이 노드의 악의 비용을 이익보다 높게 만들어 경제적으로 잘못된 정보를 체인에 제공하지 않도록 구현됩니다. 예를 들어, 스마트 콘트랙트에서 바이낸스, 코인베이스 등과 같은 중앙화된 거래소에서 BTC의 가중 가격에 액세스하려면 이러한 오라클에 의존하여 오프체인에서 액세스한 데이터를 합산하고 이를 온체인 스마트 콘트랙트로 전송하여 저장해야만 사용할 수 있습니다.
zkTLS가 해결하는 문제
그러나 이 Oracle 기반 데이터 액세스 솔루션에는 두 가지 문제가 있는 것으로 밝혀졌습니다.
1. 비용이 너무 높음: 오라클이 체인에 전달한 데이터가 위변조되지 않은 실제 데이터임을 보장하기 위해서는 지분 증명 합의 메커니즘에 의해 보장되어야 하지만, 지분 증명 합의 메커니즘의 보안은 담보된 자금의 양에 따라 구축되므로 유지보수 비용이 발생하게 됩니다. 그리고 일반적으로 지분 증명 합의 메커니즘에는 많은 양의 데이터 상호 작용 중복이 존재하는데, 이는 데이터 모음이 합의를 통과하기 전에 네트워크에서 많은 수의 반복으로 전송, 계산 및 집계되어야 하기 때문에 데이터 사용 비용도 증가하기 때문입니다. 따라서 일반적으로 오라클 프로젝트는 고객을 확보하기 위해 BTC와 같은 주류 자산의 가격 등 가장 중요한 일부 데이터만 무료로 유지합니다. 그리고 독점적인 필요에 대해서는 비용을 지불해야 합니다. 이는 애플리케이션 혁신, 특히 일부 롱테일 맞춤형 요구사항의 혁신을 저해합니다.
2. 비효율성이 너무 낮음: 일반적으로 지분 증명 메커니즘의 합의에는 일정 시간이 걸리며, 이는 체인의 데이터에 지연을 유발하여 체인에서 얻은 데이터와 실제 오프체인 데이터 사이에 큰 지연이 있기 때문에 일부 고빈도 액세스 사용 시나리오에는 바람직하지 않습니다.
위와 같은 문제를 해결하기 위해 zkTLS 기술이 등장했으며, 그 주요 아이디어는 ZKP 영지식 증명 알고리즘을 도입하여 체인 스마트 컨트랙트가 제3자로서 노드가 제공하는 데이터가 실제로 HTTPS 자원에 액세스한 후 반환된 데이터이고 변조되지 않았는지 직접 확인할 수 있어 합의 알고리즘으로 인해 기존 오라클의 높은 사용 비용을 피할 수 있다는 것입니다. 사용 비용.
왜 온체인 VM 환경에 Web2 API 호출 기능을 내장하지 않느냐고 질문하시는 분들도 계실 것입니다. 온체인 환경에서 폐쇄적인 데이터를 유지해야 하는 이유는 모든 데이터의 추적성, 즉 합의 과정에서 모든 노드가 특정 데이터나 특정 실행 결과의 정확성에 대해 통일된 평가 로직, 즉 객관적인 검증 로직을 가지고 있기 때문입니다. 따라서 완전히 신뢰할 수 없는 환경에서는 대부분의 선의의 노드가 자체적으로 보유한 중복 데이터를 통해 직접 결과의 진위 여부를 판단할 수 있습니다. 그러나 웹2 데이터의 경우, 네트워크 지연 시간 등의 이유로 인해 웹2 HTTPS 리소스에 액세스하는 여러 노드가 얻은 결과가 다를 수 있으므로 이러한 통합된 평가 로직을 구축하기가 어렵고, 특히 일부 빈도가 높은 데이터 도메인의 경우 합의에 어려움을 겪을 수 있습니다. 또한 또 다른 핵심 문제는 HTTPS 프로토콜은 암호화 키에 대한 서버 측과의 협상을 달성하기 위해 클라이언트가 생성한 난수(클라이언트 랜덤)와 키 공유 매개변수에 의존하는 TLS 프로토콜의 보안에 의존하는데, 온체인 환경이 개방적이고 투명하기 때문에 스마트 컨트랙트가 난수와 키 공유 매개변수를 유지하도록 허용하면 키 데이터가 노출된다는 점입니다. 키 데이터가 노출되어 데이터 프라이버시가 손상될 수 있습니다.
그렇다면 zkTLS는 데이터에 가용성을 제공하기 위한 기존 Oracle의 합의 기반 메커니즘의 높은 비용을 대체하는 암호화 보호로 생각되는 다른 접근 방식을 취합니다. ZK-Rollup이 L2에서 OP-Rollup을 최적화한 것과 유사합니다. 구체적으로 ZKP 영지식 증명을 도입하여 특정 HTTPS를 요청하는 체인 내 릴레이 노드가 얻은 자원, 관련 CA 인증서 검증 정보, 타이밍 증명, HMAC 또는 AEAD 기반의 데이터 무결성 증명을 계산하여 증명을 생성하고 필요한 검증 정보 및 검증 알고리즘을 체인에 유지함으로써 스마트 컨트랙트는 다음과 같은 기능을 구현할 수 있습니다. 스마트 컨트랙트는 핵심 정보를 노출하지 않고도 데이터의 진위성과 유효성, 데이터 소스의 신뢰성을 검증할 수 있습니다. 알고리즘의 구체적인 세부 사항은 여기서 설명하지 않으며, 관심 있는 파트너가 자체적으로 심층 연구를 수행할 수 있습니다.
이 기술 솔루션의 가장 큰 장점은 Web2 HTTPS 리소스의 가용성에 도달하는 데 드는 비용을 절감할 수 있다는 점입니다. 이는 특히 롱테일 자산의 온체인 가격 획득을 줄이고, 웹2.0 세계의 권위 있는 사이트를 사용하여 온체인 KYC를 수행하고, DID, 웹3.0 게임 등을 위한 기술 아키텍처 설계를 최적화하는 측면에서 많은 새로운 요구사항을 자극했습니다. 물론 기존 웹3.0 기업, 특히 현재 주류인 예언 머신 프로젝트에도 zkTLS의 영향이 존재한다는 것을 알 수 있습니다. 따라서 이러한 영향에 대처하기 위해 체인링크, 파이스 등 업계의 거대 기업들은 관련 연구 방향을 적극적으로 따르며 기술 반복 과정에서 우위를 유지하려고 노력하는 한편, 기존 시간 단위 과금에서 서비스형 컴퓨팅(Compute as a Service)의 양에 따른 과금 전환 등 새로운 비즈니스 모델을 내놓고 있습니다. 물론 대부분의 ZK 프로젝트와 마찬가지로 여기에서도 여전히 어려운 점은 컴퓨팅 비용을 낮추어 상업적으로 실행 가능하게 만드는 방법입니다.
요약하면, 파트너는 제품 설계 시 zkTLS 개발의 역학 관계에 주의를 기울이고 이 기술 스택을 적절한 영역에 통합하여 기술 아키텍처 측면뿐만 아니라 비즈니스 혁신의 새로운 방향을 모색할 수 있습니다.
Brian
Hui Xin
Aaron
YouQuan
Joy