Web Proof, 세상 모든 것의 API

들어가며

Web Proof(zkTLS)를 처음 접하게 된 것은 몇 개월전의 CT를 통해서였다. 당시 소수의 사람들로부터 언급되던 Web Proof에 대해서 나는 단순히 또 다른 버즈워드겠거니 싶어서 자세히 살펴보지 않았다. 그로부터 몇개월이 지난 후, 2024 PSE Core Program을 하면서 PSE 팀에서 진행하는 프로젝트 중 하나인 TLSNotary를 알게 되었고, 드디어 제대로 Web Proof에 대해서 공부해보게 되었다. PSE Core Program을 진행하면서 여러 프로젝트들을 만났지만, 결과적으론 TLSN을 포함한 Web Proof에 대한 내용이 가장 흥미롭게 느껴졌고, 따라서 해당 글을 통해서 Web Proof를 더 많은 사람들에게 소개해보려고 한다.

본문에 들어가기에 앞서, 먼저 CT와 다양한 컨텐츠를 통해서 이미 꽤 오랜 시간부터 현재까지 Web Proof를 알리는데 노력해온 많은 분들에 대한 감사함을 전하고 싶다. @aaronjmars, @madhavanmalolan, @Euler__Lagrange, @delitzer, @_weidai 등을 포함한 많은 사람들의 자료들이 나에게 큰 도움이 된 만큼, 나의 글 역시 누군가에게 Web Proof를 이해하는데 도움이 되었으면 좋겠다.

1. Web Proof란?

1.1 웹사이트로부터 받은 정보에 대한 증명

Web Proof란, 내가 웹사이트로부터 받은 정보를 제 삼자에게 증명할 때 제출할 수 있는 증거이다. 간단한 예시는 다음과 같다.

기존에는 웹사이트, 즉 정보를 제공하는 주체가 고유한 인증서를 사용하거나 API를 제공하는 경우에만 이러한 행위가 가능했지만, Web Proof는 임의의 어떠한 웹사이트에서도 HTTPS 응답을 통해 받은 정보에 대해 이를 증명할 수 있게 만든다.

1.2 더 포멀하게

Web Proof란, 다음과 같은 명제에 대한 증명이다; ‘웹사이트 W로부터 사용자 요청 Q에 대한 응답 R이 실제로 수신되었으며, 해당 응답 R에는 문자열 S가 포함되어 있다’. 예시로 생각해보자.

내가 @samoyedali라는 X 계정의 소유자라는 것에 대한 Web Proof를 만들고 싶다고 하자. 이는 “웹사이트 x.com으로부터 사용자 요청에 대한 응답 ‘setting.json’이 실제로 수신되었으며, 해당 응답에는 문자열 ‘screen_name: samoyedali’가 포함되어 있다”라는 명제에 대한 증명을 만든다는 것과 같은 의미이다.

또 다른 얘시로, 내가 A$AP Rocky를 팔로우하고 있다는 것에 대한 Web Proof는 “웹사이트 open.spotify.com으로부터 사용자 요청에 대한 응답 ‘following?market=from_token’이 실제로 수신되었으며, 해당 응답에는 문자열 ‘name: A$AP Rocky’가 포함되어 있다”는 명제에 대한 증명을 의미한다.

1.3 더 직관적으로

Web Proof를 한 문장으로 설명한 것 중에서 가장 인상 깊었던 문구는 @aaronjmars의 ‘세상의 모든 것에 대한 API(API on demand for anything on earth)’이다. 즉, 어떤 웹사이트든, API가 있든 없든, Web Proof를 통해서 API를 쓰는 것처럼 활용할 수 있다는 뜻이다.

2. 왜 Web Proof는 중요한가?

2.1 더 많은 데이터를 검증 가능하게 만들기

근본적으로 Web Proof가 의미있는 이유는 더 많은 데이터를 검증가능하게 만들기 때문이다. @Euler__Lagrange가 해당 영상에서 말한 것처럼, 현재 검증 가능한 데이터들은 극히 일부로, 온체인 데이터나 JWT, 이메일, verifiable credential 정도이다. Web Proof를 사용함으로써 지금의 시스템을 유지한채로 더 많은 데이터를 검증 가능하게 만들 수 있다.

더 많은 데이터를 검증가능하게 만드는 것이 중요한 이유는 무엇일까? 자산과 마찬가지로 데이터 역시 불확실성을 줄임으로써 더 높은 경제적 가치를 가질 수 있기 때문이다. 예를 들어, 머신 러닝 모델을 훈련시키는데 필요한 데이터의 경우에도, 출처를 알지도 못하는 데이터보단, 어떤 출처로부터 왔는지 검증 가능한 데이터가 훨씬 더 값질 것이다. 경제적 가치 뿐만 아니라, 블록체인을 레버리지한다면, 검증가능한 데이터를 기반으로 상호 운용성이 가능하게 된다.

2.2 Cold start problem의 해결책

사업적 측면에서 Web Proof가 중요한 이유는 Web Proof가 초기 플랫폼 비즈니스들이 공통적으로 가지는 Cold start problem의 새로운 해결책이 될 수 있기 떄문이다. Cold start problem이란, 새롭게 시장에 진입하려는 플랫폼 비즈니스들이 초기에 사용자 부족으로 인해서 충분한 네트워크 효과를 만들어내지 못하여 충분한 경쟁력을 가지지 못하는 문제를 의미한다. 이를 해결하기 위하여 기존에 사용되던 방법으로는 경제적 인센티브나, 다른 플랫폼를 레버리지함으로써 초기 유저를 확보하는 방식이었다. 예를 들어, 전자의 경우, 대표적으로 페이팔의 $10 마케팅 전략이 있고, 후자의 경우, 대표적으로 Zynga가 기존의 페이스북 유저들을 레버리지한 사례가 있다.

Web Proof를 통해 새롭게 시장에 진입하는 플랫폼 비즈니스들은 기존의 플랫폼들의 허락 없이 손쉽게 해당 플랫폼의 정보를 레버리지할 수 있다. 예를 들어, 탈중앙화 푸드 딜리버리 서비스인 Nosh의 경우, Web Proof를 통하여 드라이버들과 식당들이 ‘sign with doordash’ 버튼을 통해서 기존에 Doordash에 존재하던 자신의 정보를 그대로 Nosh에 가지고 올 수 있게 한다. 비슷하게, 온체인 라이드 쉐어링 서비스인 Teleport의 경우, Web Proof를 통하여 드라이버들이 자신의 Uber rating을 손쉽게 가져올 수 있다.

Web Proof를 활용해 기존 플랫폼의 정보를 손쉽게 새로운 서비스로 옮길 수 있게 되면서, 그동안 기성 플랫폼 비즈니스의 가장 큰 해자로 여겨졌던 네트워크 효과가 점점 중요해지지 않게 될지도 모른다. 예를 들어, Web Proof가 없었다면, Nosh나 Teleport 같은 서비스들이 더 나은 비용과 서비스를 제공하더라도, 플랫폼 참여자 입장에서는 Doordash나 Uber에서 쌓아온 평판과 데이터 때문에 쉽게 옮기기 망설여졌을 것이다. 하지만 Web Proof 덕분에 이러한 장벽이 사라진 셈이다.

3. Web Proof의 10가지 유즈 케이스들

Web Proof의 활용 방안은 무궁무진한데, 그 중에서도 실제 사례가 있거나, 나에게 가장 와닿는 것들로 10가지를 추려 보았다.

4. 조금 더 자세히

이렇게 우리는 Web Proof이 무엇이고, 왜 중요하며, Web Proof를 통하여 어떤 것들이 가능한지 알아보았다. 이번에는 Web Proof에 대해서 조금 더 자세히 알아보자.

4.1 HTTPS & TLS

왜 기존 방식으로는 제 삼자에게 내가 웹사이트로부터 받은 정보를 증명할 수 없을까? 이를 알기 위해선 HTTPS와 TLS에 대해서 먼저 알아봐야 한다.

내가 이해한 바에 따르면, HTTPS는 웹사이트와 유저 간의 통신을 암호화하여 안전하게 소통할 수 있는 프로토콜로, 기존에 패킷을 암호화하지 않고 보내는 HTTP 방식에 TLS라는 보안 프로토콜을 더한 것이다. 즉, HTTPS에서 사용하는 보안 프로토콜이 TLS인 것이다. 이 TLS를 통하여 우리가 웹사이트로부터 주고 받는 정보들은 안전하게, 노출의 위험 없이 송수신할 수 있다.

TLS 프로토콜에서 우리가 알아야하는 포인트는 웹사이트와 유저가 정보를 암호화해서 서로 보낼떄 같은 키(세션 키)를 사용한다는 것이다. 사실 TLS 프로토콜은 비대칭과 대칭 키 알고리즘을 함꼐 사용하는데, 처음 웹사이트와 유저가 연결되었을 때, 안전하게 세션 키를 교환하기 위한 핸드쉐이크 과정에서는 비대칭 키 알고리즘을 사용하고, 이후 실제 데이터 통신 시에는 하나의 세션 키, 즉 대칭 키 알고리즘을 사용한다.

4.2 TLS의 세션 키가 가지는 문제점

TLS가 비대칭 키 알고리즘과 대칭 키 알고리즘을 함께 사용하는 이유는 보안성과 효율성을 모두 만족시키기 위해서이며, 웹사이트와 유저 간의 안전한 데이터 통신에는 전혀 문제가 없다. 하지만, 나와 웹사이트 간에 주고받은 데이터를 제삼자에게 증명하려고 할 때는 이것이 꽤나 까다로운 문제로 작용한다.

웹사이트와 유저가 서로 데이터를 암호화/복호화할떄 같은 세션 키를 사용하기 때문에, 제 삼자의 입장에서는 유저로부터 전달받은 데이터가 실제로 유저가 웹사이트로부터 받은 것인지, 아니면 유저가 자의적으로 수정한 것인지 구별할 수 없다. 예를 들어, 제 삼자에게 내가 X 플랫폼의 @elonmusk 계정의 주인이라는 것을 증명하고 싶다고 하자. 이때, 제 삼자의 입장에선 다음과 같은 두 상황을 구별할 수가 없다.

따라서, 현재의 시스템 상으로는 내가 웹사이트랑 주고 받은 정보를 제 삼자에게 증명하는 것은 불가능하다. 사실 애초에 TLS는 나와 웹사이트 사이에서의 데이터 전송 시의 안전을 위해서 만들어진 것이기 때문에, 이러한 문제가 있는 것은 당연할지도 모른다.

4.3 우리가 원하는 것

Web Proof는 기존의 HTTPS 시스템을 유지한채로, 우리가 웹사이트와 주고 받는 데이터를 제 삼자에게 증명가능하게 만들어준다는 점에서 매력적이다. 그렇다면, 우리는 Web Proof로부터 어떠한 속성을 원하는 걸까? 이는 크게 Must to Have 특성 2개와 Nice to Have 특성 1개로 정리할 수 있다.

5. Web Proof의 세가지 종류

Web Proof를 구현하는 방법을 바탕으로 Web Proof는 크게 세 가지 종류로 나눌 수 있다.

5.1 MPC 기반 Web Proof

5.1.1 메커니즘

해당 종류의 Web Proof는 Mult-Party Compuation(MPC)와 Commitment scheme를 이용해서 유저가 웹사이트로부터 받은 응답을 마음대로 수정하지 못하게 한다. MPC 기반 Web Proof에선 Notary라는 주체가 새롭게 등장하는데, Notary의 역할은 크게 다음과 같다.

MPC 프로토콜과 Blind Signature의 조합을 통해서 유저는 자기 맘대로 HTTPS 응답을 복호화하여서 수정할 수 없게 되고, 제 삼자의 입장에서는 이를 통하여, 유저를 통해서 전달 받은 정보의 Provenance와 Authenticity를 신뢰할 수 있다.

5.1.2 신뢰 가정

MPC 기반 Web Proof의 신뢰 가정은 Notary가 유저와 공모하지 않아야 한다는 것이다. 만약, Notary가 유저와 공모하여서 잘못된 Commitment에도 blind signature을 한다면, 제 삼자를 속일 수 있다.

5.1.3 장단점

MPC 기반 Web Proof의 장점은 웹사이트 입장에선 MPC 기반의 Web Proof를 사용하는 것과 일반 TLS 프로토콜을 진행하고 있는 유저를 구분할 수 없다는 점이다. 단점은 네트워크 오버헤드와 레이턴시인데, 아무래도 MPC가 근본적으로 많은 연산을 필요로 하다보니, 이로 인한 효율성이 부족한 점이 있다.

5.1.4 TLSNotary(TLSN)

TLSN는 Privacy & Scaling Exploration(PSE)에서 진행하는 프로젝트로 MPC 기반 Web Proof의 가장 대표적인 프로젝트이다. 앞선 다이어그램 역시 TLSN의 독스에서 가져왔을 정도로, 앞서 설명한 내용이 TLSNotary의 메커니즘 그 자체이다.

TLSN Browser Extention을 사용하면, 손쉽게 실제 웹 브라우저에서 TLSNotary에 의한 Web Proof를 생성해볼 수 있다. 이때 Notary 서버 외에도 TLSNotary가 TCP 통신을 필요로 하기 때문에, HTTPS를 TCP로 변환해주는 Websocket Proxy 서버가 필요하다. 필요한 조건들을 갖춘 후에, 플러그인을 통해서 간편하게 Web Proof를 생성할 수 있다. 아래는 Twitter profile 증명에 대한 플러그인을 사용한 모습이다.

이후, 확장 프로그램의 Verify 기능을 통해서 우리가 원하였던 HTTPS 요청 및 응답에 대한 Web Proof가 제대로 만들어졌는지 확인할 수 있다.

TLSN을 사용한 다른 예시가 궁금한 사람들에게는 zkCredit나 @aaronjmars의 인스타그램 플러그인을 확인해보는 것을 추천한다.

5.1.5 Opacity

Opacity는 앞서 언급한 리스크인 Notary와 유저 간의 공모 가능성을 낮추기 위하여 다음과 같은 요소들을 사용한다.

아직 많은 정보가 공개되어 있지는 않지만, 앞서 언급한 프로젝트들 중에서 Nosh나 Daisy가 Opacity를 사용하는 것으로 알려져있다.

5.2 Proxy 기반 Web Proof

5.2.1 메커니즘

Proxy 기반 Web Proof에서는 Notary 대신에 Proxy라는 새로운 주체를 도입하여서 나와 웹사이트 간의 암호화된 데이터를 중간에서 전달하는 역할을 수행한다. 나의 HTTPS 요청은 Proxy를 통해서 웹사이트에게 전달되고, 웹사이트의 응답은 Proxy를 거쳐서 나에게 전달된다. 이 외에 Proxy의 역할은 크게 다음과 같다.

5.2.2 신뢰 가정

Proxy 기반 Web Proof는 MPC 기반 Web Proof와 마찬가지로 Proxy가 유저와 공모하지 않아야 한다는 신뢰 가정을 필요로 한다. 여기에 더하여, Proxy 기반 Web Proof의 경우, Proxy가 웹사이트와 직접적으로 연결되어 있고, 악의적인 유저가 해당 Proxy를 우회하지 않는다라는 가정이 추가적으로 필요하다.

5.2.3 장단점

Proxy 기반 Web Proof의 가장 큰 장점은 MPC와 같은 복잡한 암호학 프로토콜을 사용하지 않기 때문에, 연산에 대한 부담이 적고, 레이턴시도 훨씬 적다. 단점의 경우, 앞서 언급한 추가적인 네트워크 가정과 함꼐, 웹사이트에 실질적으로 연결된 IP가 유저가 아닌 Proxy이기 때문에, 큰 규모로 사용하였을 때는 밴될 리스크가 존재한다.

5.2.4 Reclaim Protocol

Reclaim Protocol은 Proxy 기반 Web Proof를 사용하는 가장 대표적인 프로젝트이다. 기본 메커니즘 자체는 위에서 설명한 부분과 거의 흡사하다. 하지만, MPC 기반 Web Proof 진영의 Opacity와 비슷하게, Reclaim Protocol 역시 Proxy와 유저 간의 공모 가능성을 줄이고, 악의적인 행동들을 막기 위하여 다수의 Proxy로 구성된 네트워크와 경제적인 인센티브/슬래싱 메커니즘을 사용한다.

Reclaim Protocol의 Demo를 통해서 실제로 Reclaim Protocol을 통해서 Web Proof를 만들어볼 수 있다. 해당 사이트에서 먼저 생성하고 싶은 증명의 종류를 선택한 뒤, QR 코드를 찍으면 모바일 앱으로 연결된다. 이후 앱에서 해당 사이트에 로그인한 뒤, 해당 정보가 포함된 페이지에 접속하면, 자동으로 Web Proof가 생성된다. 나의 경우, Kaggle Username에 대한 Web Proof를 만들기 위해서 앱에서 Kaggle 웹사이트에 로그인하였고, 다음과 같은 Web Proof를 만들 수 있었다.

최근 Reclaim Protocol은 코드를 오픈소스하였고, Reclaim을 이용해서 어플리케이션을 손쉽게 만들 수 있도록 도와주는 Devtool v3을 공개하였는데, 관심이 있는 경우 직접 확인해보기를 바란다.

5.3 TEE 기반 Web Proof

TEE 기반 Web Proof는 말 그대로 Trusted Execution Environment(TEE)를 활용하여서 유저와 웹사이트 간의 HTTPS 응답 및 요청의 Authenticity를 보장한다. TEE의 경우, 머신의 소유자조차도 해당 하드웨어 안에서 이뤄지는 연산을 변경할 수 없는데, 이를 이용한 Web Proof 메커니즘은 2016년에 발표된 Town Crier에서 처음 소개되었다. 유저는 TEE에 암호화된 사용자 로그인 정보를 제공하면, TEE는 이를 통해서 로그인 후, 웹사이트로부터 받은 응답을 보관한다. 이후 유저는 TEE에서 생성된 서명을 통해서 유저와 웹사이트 간에 교환한 데이터에 대한 Provenance와 Authenticity를 증명하게 된다.

5.3.1 신뢰 가정

TEE 기반 Web Proof의 경우, 각각의 하드웨어의 안전성과, 서명 프로세스에 대한 신뢰 가정을 필요로 한다.

5.3.2 장단점

TEE 기반 Web Proof의 가장 큰 장점은 앞서 소개한 두 종류들과 달리 Notary나 Proxy와 같은 추가적인 주체가 필요하지 않다는 것이다. 하지만, 하드웨어 스펙에 따라서 해당 방식의 보안 수준이 크게 좌우 될 수 있다는 점이 단점이다.

5.3.3 Clique

Clique는 TEE 기반 Web Proof를 사용하는 가장 대표적인 프로그램이다. Clique는 TEE 노드 네트워크를 기반으로 하여, EVM과 WASM과 같은 가상 머신에서 커스텀 바이트코드 실행을 지원한다. 현재 Intel SGX를 중심으로 작동하며, Web Proof 외에도 다양한 온체인 데이터 인증 및 인센티브 분배 등에 활용될 수 있다.

Sibyl은 Clique의 프라이버시 보호 API 솔루션으로 TEE를 활용하여서 임의의 API 호출을 통해 접근한 데이터의 Provenance와 Authenticity를 제공한다. 이 API 호출을 바탕으로 ZKP를 생성하는 것도 가능하며, TEE가 실제로 예상한대로 연상을 실행하였다는 것에 대한 ECDSA 서명을 생성하여서, Intel의 Root CA를 통해서 이를 온체인 상에서 검증할 수도 있다.

6. Q&A

마지막으로 Web Proof에 대해서 알면 좋을 TMI들을 Q&A 형식으로 공유해보려고 한다.

6.1 왜 나는 zkTLS 대신 Web Proof라는 용어를 사용하였는가?

사실 이미 눈치 챈 사람들도 있겠지만, 내가 지금까지 Web Proof라고 부른 것은 많은 사람들이 zkTLS라고 부르는 개념이다. 내가 굳이 많은 사람들이 사용하는 zkTLS라는 용어가 아닌 Web Proof라는 단어를 사용한 이유는 해당 개념에서 ZK가 핵심이 아니기 때문이다.

Web Proof에서 Provenance와 Authenticity는 필수로 가져야하는 속성이지만, Selective Disclosure는 Nice to Have 속성이다. 그리고, Web Proof의 메커니즘을 살펴보면, ZK가 사용되더라도 대부분 Selective Disclosure 부분에 사용되고, Provenance와 Authenticity는 각각 MPC, Proxy, 그리고 TEE라는 별개의 방식을 사용하여서 보장하게 된다. 즉, zk가 핵심적인 요소로써 사용되지 않기 때문에, zkTLS라는 명칭보다는 그 기능을 더 잘 나타내는 Web Proof라는 용어가 더 적절하다는 것이 나를 포함하여 Web Proof라는 용어를 사용하는 사람들의 생각인 것 같다.

6.2 그냥 웹사이트가 서명을 하면 안되는건가?

만약 우리가 모든 웹사이트들이 응답에 대한 서명을 진행하는 세상에 산다면, 사실 Web Proof는 필요하지 않다. Web Proof가 존재하는 근본적인 이유는 HTTPS 통신에서 유저와 웹사이트가 디지털 서명이 아닌 하나의 세신 키를 사용하여서 암호화/복호화를 진행하기 때문이다.

실제로 Signed Exchanges(SXG)는 웹사이트가 자신의 컨텐츠에 대한 디지털 서명을 하는 메커니즘으로, 원래는 Google에서 컨텐츠를 사전에 캐시하여서 웹사이트의 로딩 속도를 높이기 위해서 사용되지만, 웹사이트들의 데이터에 대한 authenticity를 제공하는데도 사용할 수 있다. Cloudflare를 통해서 호스팅하는 웹사이트의 경우, SXG를 손쉽게 설정할 수 있다. 이와 관련된 더 자세한 내용은 @viv_boop의 해당 포스트를 참고하기를 바란다. 이 외에도 아마존 팀에서 제안한 HTTPS 메시지의 일부로써 디지털 서명을 생성하고, 이를 검증하는 표준 역시 참고해볼만 하다.

결론적으로, 소수의 웹사이트들이 서명을 도입할 가능성은 있지만, 거대 인터넷 플랫폼들 입장에서는 이를 도입할 특별한 인센티브가 없기 때문에, 더 많은 데이터를 검증 가능하게 만들기 위해서는 Web Proof가 현실적으로 가장 나은 대안이라고 생각한다.

6.3 법적인 문제는 없는가?

Web Proof의 합법성에 대한 @dbarabander의 재밌는 포스트를 보게 되어서 해당 부분을 추가해봤다.

일부 사람들은 인터넷 플랫폼들의 약관을 보면 대부분 자동화된 도구를 사용해 데이터를 수집하는 행위를 금지하고 있기 때문에, 사용자가 특정 소프트웨어를 통해 자신의 데이터에 대한 Web Proof를 생성하고 활용하는 것이 컴퓨터 범죄 및 남용 방지법(CFAA)을 위반할 수 있다고 생각할 수 있다. 그러나 해당 포스트에 따르면, Web Proof 브라우저 확장 솔루션이 사용자의 계정을 직접적으로 제어하지 않는다면 이는 위반이 아니라고 판단하고 있다.

소프트웨어 제공자가 사용자의 계정에 대한 권한이 없다면, 데이터를 소유한 본인이 제공자의 서버에 요청을 보내는 것이기 때문에, 제공자가 ‘unauthorized access’에 개입했다고 보기 어렵다는 것이 주요 논리이다. Web Proof의 합법성에 대해 더 깊이 알고 싶다면, 해당 포스트의 본문을 직접 확인해보는 것을 추천한다.

7. 마무리하며

최근 몇 주 동안 내가 공부한 Web Proof에 대하여 도대체 이게 왜 중요한지, 그리고 무엇인지 소개해보았다. 물론, Web Proof가 더 많은 어플리케이션에 도입되기 위해서는 여전히 개발자 및 사용자 경험, 레이턴시 문제, 다이내믹 데이터에 대한 증명 등 여러 가지 장애물들이 존재한다. 하지만, 내가 보기에는 이러한 문제들은 온체인 네이티브 어플리케이션들이 직면한 장애물들에 비하면 비교적 사소한 부분이다. 또한, 이미 Web Proof를 활용하는 다양한 어플리케이션들이 있다는 점에서, Web Proof는 더 이상 미래의 기술이 아니라, 현재에도 충분히 상용화 가능한 기술이라고 생각한다. 앞으로 Web Proof를 기반으로 더 많은 어플리케이션들이 등장하기를 기대하며, 관련된 흥미로운 프로젝트가 나오면 그떄 또다시 소개하도록 하겠다.

8. 출처