Chainlink DECO를 한 문장으로 이해하기: 개인정보 보호 기능을 갖춘 오라클
글: kokii.eth,启明创投 인턴
0. 서론
Web3은 데이터의 가치를 재정립했지만, 분산 구조의 블록체인은 폐쇄적인 결정론적 시스템이며 스마트 계약은 외부 API 호출 기능을 제공하지 않기 때문에 외부 데이터를 스마트 계약에 전달하기 위한 오라클 메커니즘이 등장하게 되었다.
오프체인 데이터를 체인에 올리는 것은 본질적으로 어렵지 않지만 중요한 것은 기술과 메커니즘 설계를 통해 신뢰를 생성하는 것이다. 오라클 문제란 데이터 소스에서부터 처리, 가격 정보 제공에 이르는 전 과정에서 신뢰를 확보해야 하는 문제를 말한다.
대중이 인정하는 오라클이 되기 위한 기본 조건은 탈중앙화이다. 즉, 단일 장애 지점(SPOF) 허용 여부와 데이터 검증 가능 여부가 핵심이다. 오프체인 탈중앙화의 일반적인 해결책은 여러 데이터 노드를 사용해 탈중앙화된 오라클 네트워크를 구성하는 것으로, 각 노드가 데이터를 수집하고 합의를 거쳐 블록체인 상의 스마트 계약에 입력한다.
체인링크 아키텍처
현재 오라클의 주요 용도는 DeFi에 Price Feed(가격 정보 제공)를 제공하는 것으로, 기초 자산의 가격을 안전하고 신속하며 정확하게 업데이트하는 것이다. DefiLlama 데이터에 따르면 체인링크는 시장에서 가장 큰 오라클 솔루션 중 하나로, 본문 작성 시점 기준 약 110억 달러의 총 가치를 보증하며 전체 시장의 46%를 차지하고 있다.
오라클 시장 데이터
블록체인의 발전과 함께 오프체인 데이터에 대한 수요는 점점 더 커지고 있으며, 단순히 DeFi에 가격 정보를 제공하는 것만으로는 개발자의 요구를 충족시키기 어렵다. 현실 세계와 Web2의 대부분의 데이터는 공개 접근이 불가능하지만, Web3 혁신 애플리케이션 시나리오(신용 대출, 소셜, DID, KYC/AML 등) 구축에는 반드시 필요하다. 따라서 차세대 오라클은 민감한 데이터 관련 복잡한 사용 사례를 개인정보를 보호하면서 스마트 계약이 지원할 수 있도록 해야 한다.
DECO 는 체인링크가 이러한 방향에서 제시한 솔루션으로, 제로 난지 증명(ZKP) 기술을 활용하여 사용자가 오프체인 개인정보에 대한 증명을 스마트 계약에 생성할 수 있게 하되, 데이터 자체를 대중이나 오라클 노드에 공개하지 않는다.
DECO는 기존 API에 연결 가능하며, 최종 사용자 인증이 필요한 경우(예: 은행 계좌 잔액 조회 시 로그인 필요)에도 API 데이터 제공업체 측에서 아무런 수정 없이 사용할 수 있다. 현재 알파 단계에 있으며 다수의 파트너와 함께 개념 검증(Proof of Concept)을 진행 중이다.
1. 배경 지식
여기서는 TLS와 ZKP에 대한 필수 배경 지식을 제공한다. DECO는 이러한 프로토콜 위에 구축된다.
1.1 TLS
TLS(Transport Layer Security, 전송 계층 보안)은 강력하고 널리 배포된 보안 프로토콜로, 이전 이름은 SSL이며 인터넷 통신의 비밀성과 데이터 보안을 보장하기 위해 고안되었다. 애플리케이션 프로토콜 계층과 TCP/IP 계층 사이에 위치하며 주로 웹 애플리케이션과 서버 간 통신을 암호화하는 데 사용된다.
HTTP를 통한 통신은 모두 평문으로 이루어져 도청, 변조, 사칭이 용이하다. TLS 사용 시 사용자가 웹사이트에 보내는 HTTP 데이터(클릭, 폼 작성 등)와 웹사이트가 사용자에게 보내는 HTTP 데이터는 모두 암호화되며 수신자는 키를 사용해 암호화된 데이터를 복호화해야 한다. HTTPS는 HTTP 프로토콜 위에 TLS 암호화를 적용한 것으로 웹사이트의 표준 방식이며, 웹사이트는 원본 서버에 TLS 인증서를 설치해야 하고 브라우저는 모든 비HTTPS 웹사이트를 '비보안'으로 표시한다.
비HTTPS 웹사이트
TLS의 기본 아이디어는 공개키 암호화 방식을 채택하는 것으로, 웹사이트가 공개적으로 공유하는 TLS/SSL 인증서에는 공개키가 포함되어 있고 비밀키는 원본 서버에 설치되어 웹사이트 소유자가 관리한다. 클라이언트는 먼저 서버로부터 디지털 인증서의 공개키를 요청한 후 이 공개키로 정보를 암호화하고, 서버는 암호문을 수신한 후 자신의 비밀키로 복호화한다.
여기서 한 가지 문제가 있는데, 공개키 암호화는 계산량이 매우 크기 때문에 세션 시간을 줄이기 위해 매 세션마다 클라이언트와 서버가 "세션 키(session key)"를 생성하여 이를 이용해 정보를 암호화한다. 세션 키는 대칭형 암호화이므로 연산 속도가 매우 빠르며, 서버의 공개키는 세션 키 자체를 암호화하는 데만 사용되므로 암호화 연산의 소모 시간을 줄일 수 있다.
따라서 TLS 프로토콜은 주로 두 계층으로 나뉜다:
-
인증 및 키 협상 핸드셰이크 프로토콜(handshake protocol): 평문 통신을 통해 비대칭 암호화를 사용해 서로의 신원을 확인하고 사용할 암호화 알고리즘을 결정하며 기록 프로토콜의 대칭 암호화에 사용할 일관된 세션 키를 생성한다.
-
대칭 암호화 전송 기록 프로토콜(record protocol): 프로토콜의 본체로서 데이터 전송의 기밀성과 무결성을 보호한다.
TLS 프로토콜 스택
TLS의 암호화 묶음(CipherSuite)은 4가지 알고리즘의 조합이다:
-
인증(Authentication): 신원의 진위를 판단하며 RSA/DSA/ECDSA 등이 주류이다.
-
키 교환(Key exchange): 통신 양측이 암호화에 사용할 키를 협상하며 ECDHE 등이 주류이다.
-
암호화(Encryption): 통신에 사용되는 대칭형 암호화이며 GCM 사용이 추세이다.
-
MAC(Message Authentication Code, 메시지 인증 코드): 데이터 무결성 및 변조 여부를 검증하며 SHA256/SHA384/SHA1 등이 주류이다.
TLS는 매우 강력하지만 한 가지 제한이 있다: 사용자가 자신이 접속한 데이터가 특정 웹사이트에서 실제로 왔음을 제3자에게 입증할 수 없다. 데이터 전송에 대칭형 암호화를 사용하므로 사용자와 서버 모두 데이터에 서명할 능력을 갖추고 있기 때문이다. 직관적인 예로 Alice의 신원 정보를 저장하고 있는 수많은 웹사이트 서버는 Alice가 만 18세 이상임을 쉽게 확인할 수 있지만, Alice 본인이 Bob에게 이를 증명하기는 어렵다. Alice는 웹사이트에서 스크린샷을 찍을 수 있지만, 스크린샷은 쉽게 위조될 수 있고, 심지어 스크린샷이 진짜임이 입증되더라도 정보 유출 문제가 발생한다—Alice의 정확한 생년월일이 노출되며, 단지 만 18세 이상이라는 사실만 알려주는 것이 아니다.
오라클은 탈중앙화(웹사이트 서버 같은 단일 지점에 의존하지 않음)를 통해 오프체인 개인정보의 출처(Provenance)를 입증하고 개인정보를 노출하지 않은 상태에서 스마트 계약이 사용할 수 있도록 해야 한다. 제로 난지 증명(ZKP)은 이러한 기능을 실현하는 데 도움을 줄 수 있다.
1.2 ZKP
제로 난지 증명(Zero Knowledge Proof, ZKP)은 블록체인 분야에서 광범위한 관심을 받고 있으며 주로 ZK-Rollup(확장성 효율성을 위해 알고리즘 설계에서 많은 타협을 한, 실제론 'zk'가 아닌 유효성 증명)과 개인정보 보호 기술(진정한 'zk')에 응용된다. 제로 난지 증명은 증명자(Prover)가 검증자(Verifier)에게 어떤 계산 문제(Statement)에 대한 해(Witness)를 가지고 있음을 증명하면서도 그 해(Witness)에 관한 추가 정보를 전혀 공개하지 않는 것을 가능하게 한다.
전형적인 ZK 시스템은 프론트엔드와 백엔드로 나뉜다.
-
프론트엔드: 컴파일러로서 검증할 Statement를 특정 도메인 언어(DSL)로 작성한 후 ZK 친화적인 형식(예: 산술 회로)으로 컴파일한다.
-
백엔드: 회로의 정확성을 검사하는 대화형 논증 시스템으로 Marlin, Plonky2, Halo2 등이 있다.
ZK 시스템
블록체인과 같은 개방형 시스템에서 대화형 질의 응답 프로세스를 구성하는 것은 매우 복잡하며, 증명은 누구나 언제든지 검증할 수 있어야 하므로 블록체인 애플리케이션의 ZK 시스템은 일반적으로 비대화형(non-interactive)이다. 대화형 방식은 Fiat–Shamir 휴리스틱을 사용해 비대화형으로 변환할 수 있다.
2. DECO 작동 방식
DECO는 HTTPS/TLS 프로토콜을 기반으로 확장하여 서버 측에서 수정 없이 사용할 수 있도록 한다.
DECO의 핵심 아이디어는 증명자(Prover, 사용자 또는 DECO Prover를 실행하는 Dapp), 검증자(Verifier, DECO Verifier를 실행하는 Chainlink 오라클), 서버(Server, 데이터 제공자) 사이에 새로운 3자간 핸드셰이크 프로토콜을 구축하는 것이다.
-
출처 증명(Provenance): Prover가 웹 서버에서 정보를 조회할 때 Verifier는 상호작용 과정을 목격하고 Prover가 TLS 세션 데이터로부터 생성한 커밋먼트(Commitment)를 수신함으로써 정보의 진정한 출처를 검증할 수 있다.
-
개인정보 보호(Privacy): 데이터에 개인정보 보호가 필요 없으면 Prover는 Verifier에게 데이터를 복호화할 수 있는 키를 직접 제공하여 개발자가 Dapp에 데이터를 추가할 수 있다. 개인정보 보호가 필요하면 Prover는 ZKP를 사용해 데이터를 노출하지 않고 증명을 생성하여 개발자가 Dapp에 추가할 수 있다.
DECO 예시
구체적으로 DECO 프로토콜은 세 단계로 구성된다:
-
3자 핸드셰이크: Prover, Verifier, Server가 특수 형식의 세션 키를 설정하여 데이터 위변조를 방지한다.
-
쿼리 실행: Prover는 개인 파라미터 θs(예: 계정 비밀번호, API 키)가 포함된 쿼리를 사용해 Server에서 데이터를 조회한다.
-
증명 생성: Prover는 응답이 필요한 조건을 충족함을 증명한다.
DECO 아키텍처
2.1 3자 핸드셰이크
참고: 다음 설명은 AES-CBC-HMAC 암호화 알고리즘을 기반으로 하며, TLS 1.3은 AEAD라는 더 안전한 암호화 알고리즘만 유지하여 암호화와 MAC에 동일한 키를 사용하므로 MAC 키가 필요하지 않다. 그러나 TLS 1.3의 키 독립성 덕분에 유사한 복잡도의 3자 핸드셰이크 프로토콜을 구축할 수 있다.
Prover P는 MAC 키를 획득한 후 커밋먼트를 만들 수 없어야 한다. 그렇지 않으면 데이터를 위조하거나 변조할 수 있기 때문이다. 따라서 3자 핸드셰이크의 핵심 아이디어는 Prover P와 Verifier V를 함께 TLS 클라이언트로 간주하고 TLS 서버 S와 공유 MAC 키를 설정하는 것이다. MAC 키 k는 클라이언트 측에서 분할되며, Prover는 kp를 보유하고 Verifier는 kv를 보유하며, k=kp+kv이다. 동시에 P는 대칭형 암호화 알고리즘에 사용할 암호화 키 k^{Enc}도 보유한다. Verifier가 악의를 가지지 않는다면 3자 핸드셰이크 프로토콜은 데이터가 위변조되지 않도록 보장한다.
2.2 쿼리 실행
핸드셰이크 후 MAC 키는 비밀 공유되므로 P와 V는 상호작용 프로토콜(양자 간 안전한 계산)을 수행하고 개인 파라미터 θs를 사용해 암호화된 쿼리 TLS 메시지 Query Q를 구성한다. 이후 P는 표준 TLS 클라이언트로서 Q를 S에 전송하며, 이 과정에서 P와 S만 통신하며 P가 전송하는 쿼리는 V에게 전혀 노출되지 않는다.
S로부터 응답 R을 수신한 후, P는 암호문 Rˆ를 V에게 보내 세션에 대한 커밋먼트를 하고, V로부터 kv를 수신하여 응답 R의 진위를 검증한다.
2.3 증명 생성
다음으로 P는 암호문 Rˆ에 해당하는 평문 R이 특정 속성을 만족함을 증명해야 한다. 개인정보 보호가 필요 없으면 암호화 키 k^{Enc}를 직접 공개하면 되고, 개인정보 보호가 필요하면 제로 난지 증명을 사용해야 한다.
평문이 여러 데이터 블록으로 구성되어 R=(B1,...,Bn)라고 가정하면, DECO는 선택적 공개(Selective Opening)를 사용해 제로 난지 증명을 생성한다:
-
특정 데이터 행만 공개: 다른 데이터 블록을 공개하지 않은 채 평문 R의 i번째 데이터 블록이 Bi임을 증명한다.
-
개인정보가 포함된 데이터 행 숨기기: R_{-i}와 R이 Bi를 제외하고 동일함을 증명한다.
그러나 종종 Verifier는 공개된 하위 문자열이 올바른 문맥에 나타났는지 검증해야 하며, 위에서 언급한 방법만으로는 문맥의 무결성 보호를 충분히 제공하지 못한다. 이를 보완하기 위해 DECO는 제로 난지 2단계 파싱(Two-stage Parsing)이라는 기술을 활용한다: Prover는 로컬에서 자신의 세션 데이터를 파싱하여 Verifier를 납득시킬 수 있는 최소 하위 문자열을 결정한 후 Verifier에게 데이터를 전송한다. 이를 통해 개인정보 보호를 실현한다.
간결한 비대화형(NIZK) 제로 난지 증명은 일반적으로 Prover 측에서 계산 및 메모리 측면에서 높은 오버헤드를 가진다. DECO에서 수행되는 ZKP의 검증자는 지정되어 있으므로(Chainlink 오라클), 보다 효율적인 대화형 제로 난지 증명을 사용할 수 있으며, 이는 메모리 사용량 감소, 신뢰할 수 있는 설정 회피, 저렴한 계산 등의 장점을 가진다.
현재 알파 테스트에서는 여전히 Dapp이 Prover 역할을 하고 있으나, 향후 반복 개선에서 Prover가 최종 사용자 측에서 로컬 배포(예: 모바일 폰)되거나 신뢰 실행 환경(TEE) 내에서 배포될 계획이다.
3. 응용 분야
DECO는 사용자의 오프체인 신원 정보의 유효성을 검증하면서도 데이터 개인정보를 보호할 수 있으므로 경제에서 소셜까지 다양한 Web3 혁신 애플리케이션 시나리오를 가능하게 한다.
- 자기관리형소셜 리커버리/법적 신원 증명(당신은 누구인가): DECO를 사용해 이미 성숙한 신원 인증 메커니즘을 갖춘 기관 웹사이트(은행, 소셜 미디어)를 소셜 리커버리 수호자 중 하나로 활용할 수 있다.
- 신용 대출/자금 증명(당신은 얼마를 가지고 있는가): Teller는 DeFi 신용 대출 프로토콜로, DECO 프로토콜을 사용해 사용자의 오프체인 은행 계좌 자산 잔액이 대출 요건의 동적 최소 기준을 초과했음을 증명한다.
-
팬 증명/상호작용 증명(누구와 상호작용했는가): Clique는 소셜 오라클로서 다양한 소셜 미디어 플랫폼(예: Twitter API 사용)에서의 오프체인 사용자 영향력, 충성도 및 기여도에 대한 심층 분석을 제공하는 솔루션을 개발 중이다.
-
디지털 신원/소셜 신원 증명(당신이 특정 온라인 계정을 소유하고 있음): PhotoChromic은 디지털 신원 솔루션으로, DECO를 사용해 Web3 사용자를 Twitter 또는 Discord 소셜 계정과 연결하면서 바닥 개인정보 데이터를 노출하지 않아 애플리케이션이 진정한 사용자를 필터링할 수 있도록 한다.
-
DAO의 시빌 공격 방지, SBT, KYC/AML 등.
4. 기타 주요 참여자
-
Axiom은 Uniswap TWAP용 ZK 오라클을 구축하며, 완전히 체인 내에서 검증 가능한 데이터 소스를 사용하는 것으로 Indexing(예: Hyper Oracle)과 유사하다. DECO와는 보완 관계에 가깝고 경쟁 관계라기보다는: 점점 더 많은 경제 활동이 체인 내에서 발생하므로 순수 체인 내 오라클은 하나의 방향이며, 점점 더 많은 오프체인 데이터가 체인에 올라야 하므로 오프체인 개인정보 오라클도 또 다른 방향이다.
-
Empiric Network는 zk 컴퓨팅을 활용해 전체 오라클을 체인 내에 배치하며, 데이터가 흐르는 오프체인 인프라가 필요 없으므로 DECO와는 다른 방향이다.
5. 결론
현재 오라클 분야의 절대적 선두인 체인링크는 DECO 오라클을 통해 방대한 양의 오프체인 개인정보를 개인정보 보호 조건 하에서 체인상 스마트 계약이 호출할 수 있게 하여 금융에서 신원, 소셜에 이르기까지 다양한 애플리케이션 시나리오를 가능하게 할 것이다.
잠재적 우려는 Prover의 증명 생성 속도와 Verifier의 중심화 문제이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
