원문 기사 작성자 @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, ChaCha 20)를 사용하여 데이터를 보호하고 도청을 방지합니다.
2. 신원 인증: 지정된 기관에 제3자가 발급한 디지털 인증서(예: X.509 인증서)를 사용하여 서버의 신원을 확인하고 중간자 공격(MITM)을 방지합니다.
3. 데이터 무결성: HMAC(해시 메시지 인증 코드) 또는 AEAD(인증 암호화)를 사용하여 데이터가 변조되지 않았는지 확인합니다.
데이터 상호작용 프로세스에서 TLS 프로토콜을 기반으로 하는 HTTPS 프로토콜의 기술적 세부 사항을 간략히 설명하겠습니다. 전체 프로세스는 두 단계로 나뉩니다. 첫 번째는 핸드셰이크 단계입니다. 즉, 클라이언트와 서버가 보안 매개변수를 협상하고 암호화된 세션을 설정합니다. 두 번째는 세션 키를 사용하여 암호화된 통신을 하는 데이터 전송 단계입니다. 구체적인 과정은 4단계로 나뉩니다.
1. 클라이언트가 ClientHello를 보냅니다.
클라이언트(예: 브라우저)는 다음을 포함하는 ClientHello 메시지를 서버로 보냅니다.
지원되는 TLS 버전(TLS 1.3 등)
지원되는 암호화 알고리즘(AES-GCM, ChaCha 20과 같은 암호화 제품군)
클라이언트 랜덤(키 생성에 사용됨)
키 공유 매개변수(예: ECDHE 공개 키)
SNI(서버 이름 표시)(선택 사항, HTTPS에서 여러 도메인 이름을 지원하는 데 사용됨)
그 목적은 서버에 클라이언트의 암호화 기능을 알리고 보안 매개변수를 준비하는 것입니다.
2. 서버는 ServerHello를 보냅니다.
서버는 다음을 포함하는 ServerHello 메시지로 응답합니다.
선택된 암호화 알고리즘
서버 랜덤
서버의 인증서(X.509 인증서)
서버의 키 공유 매개변수(예: ECDHE 공개 키)
완료 메시지(핸드셰이크가 완료되었음을 확인하는 데 사용됨)
그 목적은 클라이언트에게 서버의 신원을 알리고 보안 매개변수를 확인하는 것입니다.
3. 클라이언트가 서버를 인증합니다.
클라이언트는 다음을 수행합니다.
서버 인증서를 확인하세요. 인증서가 신뢰할 수 있는 CA(인증 기관)에서 발급되었는지 확인하고 인증서가 만료되었거나 취소되었는지 확인하세요.
공유 키 계산: 사용자 자신의 ECDHE 공개 키와 서버의 ECDHE 공개 키를 사용하여 세션 키를 계산합니다. 이 세션 키는 후속 통신을 위한 대칭 암호화(예: AES-GCM)에 사용됩니다.
완료 메시지 보내기: 핸드셰이크 데이터의 무결성을 증명하고 중간자 공격(MITM)을 방지합니다.
그 목적은 서버가 신뢰할 수 있는지 확인하고 세션 키를 생성하는 것입니다.
4. 암호화된 통신을 시작합니다.
이제 클라이언트와 서버는 협상된 세션 키를 사용하여 암호화된 통신을 진행합니다.
대칭 암호화(AES-GCM, ChaCha 20 등)는 속도와 보안을 높이기 위해 데이터를 암호화하는 데 사용됩니다.
데이터 무결성 보호: AEAD(예: AES-GCM)를 사용하여 변조를 방지합니다.
따라서 이러한 4단계를 거치면 HTTP 프로토콜 문제는 효과적으로 해결될 수 있습니다. 그러나 Web2 네트워크에서 널리 사용되는 이 기본 기술은 Web3 애플리케이션 개발에 문제를 일으켰으며, 특히 온체인 스마트 계약이 특정 오프체인 데이터에 액세스하려고 할 때 그렇습니다. 데이터 가용성 문제로 인해 온체인 가상 머신은 모든 데이터의 추적성을 보장하기 위해 외부 데이터를 호출하는 기능을 열지 않아 합의 메커니즘의 보안을 보장합니다.
그러나 여러 차례의 반복을 거친 후, 개발자들은 DApp에서 여전히 오프체인 데이터에 대한 수요가 있다는 것을 알게 되었고, Chainlink와 Pyth와 같은 일련의 오라클 프로젝트가 등장했습니다. 그들은 온체인 데이터와 오프체인 데이터 간의 릴레이 브리지 역할을 하여 이러한 데이터 사일로 현상을 깨뜨립니다. 동시에 릴레이 데이터의 가용성을 보장하기 위해 이러한 오라클은 일반적으로 PoS 합의 메커니즘을 통해 구현됩니다. 즉, 릴레이 노드의 악의적 행동 비용이 이익보다 높기 때문에 경제적 관점에서 체인에 잘못된 정보를 제공하지 않습니다. 예를 들어, 바이낸스와 코인베이스와 같은 중앙집중형 거래소에서 스마트 계약을 통해 BTC의 가중 가격에 접근하려면 이러한 오라클에 의존하여 데이터에 접근하고 오프체인으로 집계한 다음, 사용하기 전에 온체인 스마트 계약으로 전송하여 저장해야 합니다.
zkTLS는 어떤 문제를 해결하나요?
하지만 사람들은 이 Oracle 기반 데이터 수집 솔루션에 두 가지 문제가 있다는 것을 발견했습니다.
1. 과도한 비용: Oracle이 체인에 전송한 데이터가 진짜이고 변조되지 않았는지 확인하기 위해 PoS 합의 메커니즘이 필요하다는 것을 알고 있습니다. 그러나 PoS 합의 메커니즘의 보안은 약속된 자금의 양에 따라 달라지므로 유지 관리 비용이 발생합니다. 게다가 일반적으로 PoS 합의 메커니즘에는 많은 데이터 상호작용 중복이 존재합니다. 이는 데이터 세트가 합의를 통과하기 전에 네트워크에서 반복적으로 전송, 계산, 요약되어야 하기 때문에 데이터 사용 비용도 증가하기 때문입니다. 따라서 일반적으로 Oracle 프로젝트는 고객을 유치하기 위해 BTC와 같은 대중적인 자산의 가격 등 가장 대중적인 일부 데이터만 무료로 유지합니다. 특별한 요구 사항이 있는 경우에는 비용을 지불해야 합니다. 이는 애플리케이션 혁신, 특히 일부 롱테일 맞춤형 수요를 방해합니다.
2. 효율성이 너무 낮음: 일반적으로 PoS 메커니즘의 합의에는 일정 시간이 걸리며, 이로 인해 온체인 데이터의 지연이 발생합니다. 이는 일부 고주파 액세스 시나리오에 적합하지 않습니다. 체인에서 얻은 데이터와 실제 오프체인 데이터 사이에 지연이 크기 때문입니다.
위의 문제를 해결하기 위해 zkTLS 기술이 등장했습니다. 이 기술의 주요 아이디어는 ZKP 제로 지식 증명 알고리즘을 도입하여 온체인 스마트 계약이 제3자 역할을 하여 노드가 제공한 데이터가 실제로 특정 HTTPS 리소스에 액세스한 후 반환된 데이터이고 변조되지 않았는지 직접 확인할 수 있도록 하는 것입니다. 이를 통해 합의 알고리즘으로 인해 발생하는 기존 Oracle의 높은 사용 비용을 피할 수 있습니다.
일부 친구들은 왜 Web2 API를 온체인 VM 환경에서 직접 호출하는 기능을 구축하지 않는지 묻고 싶어할 수도 있습니다. 답은 아니요입니다. 폐쇄된 데이터가 온체인 환경에서 유지되어야 하는 이유는 모든 데이터의 추적성을 보장하기 위한 것입니다. 즉, 합의 프로세스에서 모든 노드는 특정 데이터 또는 특정 실행 결과의 정확성에 대한 통일된 평가 논리 또는 객관적인 검증 논리를 갖습니다. 이를 통해 완전히 신뢰할 수 없는 환경에서도 대부분의 선의의 노드는 자체 중복 데이터에 의존하여 직접적인 결과의 진위 여부를 확인할 수 있습니다. 그러나 Web2 데이터로 인해 이러한 통합된 평가 논리를 구축하는 것이 어렵습니다. 네트워크 지연으로 인해 여러 노드가 Web2 HTTPS 리소스에 액세스할 때 다른 결과를 얻을 수 있기 때문입니다. 이로 인해 합의에 어려움이 가중되며, 특히 일부 고주파 데이터 영역에서는 어려움이 더 큽니다. 또한, 또 다른 핵심 문제는 HTTPS 프로토콜이 의존하는 TLS 프로토콜의 보안이 클라이언트에서 생성한 난수(클라이언트 난수)(키 생성용)와 키 공유 매개변수에 의존하여 암호화 키에 대한 서버와의 협상을 달성한다는 것입니다. 그러나 우리는 온체인 환경이 개방적이고 투명하다는 것을 알고 있습니다. 스마트 계약이 난수와 키 공유 매개변수를 유지하면 키 데이터가 노출되어 데이터 프라이버시가 손상됩니다.
그런 다음 zkTLS는 또 다른 접근 방식을 채택합니다. 그 아이디어는 암호화 보호를 통해 데이터 가용성을 제공하기 위해 기존 Oracle 기반 합의 메커니즘의 높은 비용을 대체하는 것입니다. L2의 ZK-Rollup을 통한 OP-Rollup 최적화와 유사합니다. 구체적으로 ZKP 제로 지식 증명을 도입하고, 특정 HTTPS를 요청하는 오프체인 릴레이 노드가 얻은 리소스에 대한 Proof를 계산하고 생성하며, 관련 CA 인증서 검증 정보, 타이밍 증명, HMAC 또는 AEAD 기반의 데이터 무결성 증명을 계산하고 생성하고, 체인에 필요한 검증 정보와 검증 알고리즘을 유지함으로써 스마트 계약은 핵심 정보를 노출하지 않고도 데이터 소스의 진위성, 효과성, 신뢰성을 검증할 수 있습니다. 여기서는 구체적인 알고리즘에 대한 세부 사항을 논의하지 않으며, 관심이 있는 사람은 스스로 심도 있게 연구할 수 있습니다.
이 기술 솔루션의 가장 큰 장점은 Web2 HTTPS 리소스의 가용성을 달성하는 데 드는 비용을 줄여준다는 것입니다. 이는 특히 롱테일 자산의 온체인 가격 취득을 줄이고, Web2 세계에서 권위 있는 웹사이트를 사용하여 온체인 KYC를 수행하고, 이를 통해 DID 및 Web3 게임의 기술적 아키텍처 설계를 최적화하는 데 대한 많은 새로운 수요를 자극했습니다. 물론, zkTLS가 기존 Web3 기업, 특히 현재 주류 오라클 프로젝트에 영향을 미치는 것을 알 수 있습니다. 따라서 이러한 영향에 대처하기 위해 Chainlink와 Pyth와 같은 업계 거물들은 관련 방향의 연구를 적극적으로 추진하여 기술 반복 과정에서 지배적인 위치를 유지하려고 노력하고 있습니다. 동시에 원래 시간 기반 요금에서 사용 기반 요금으로 전환하는 것과 같은 새로운 비즈니스 모델도 탄생시킬 것입니다. Compute as a service 등. 물론 여기서의 어려움은 대부분의 ZK 프로젝트와 마찬가지로 컴퓨팅 비용을 어떻게 줄이고 상업적으로 가치 있게 만들 것인가 하는 것입니다.
요약하자면, 제품을 설계할 때 zkTLS 개발에도 주의를 기울이고 이 기술 스택을 적절한 측면에서 통합할 수도 있습니다. 아마도 비즈니스 혁신과 기술 아키텍처에서 새로운 방향을 찾을 수 있을 것입니다.
