이더리움 위의 프라이버시 | 이더리움 코리아 원 : 제네시스

Transcript

프라이버시 부스트를 왜 써야 하냐? 그런 얘기도 당연히 가능하지만, 이걸 빌딩하면서 어떤 어려움이 있었고, 그걸 어떻게 해결했고, 어떤 이슈를 선택했더니 장단점이 있는 거고, 이런 얘기를 위주로 해보려고 합니다. 그래서 발표 시작하도록 할게요. 일단은 저희가 프라이버시 부스트를, 되게 당연한 얘기일 수 있는데, 프라이버시 부스트를 빌딩하게 된 계기랑 그 과정에서 어떤 선택들을 했고, 기존 솔루션들은 어떤 장단점이 있어서 우리는 어떤 선택을 했는가, 이런 얘기를 좀 해보려고 합니다.

사실 온체인 프라이버시가 지금 기관들이 많이 들어오면서 되게 당연하게 여겨지고 있는 부분이 있지만, 그래도 짚고 넘어가자면, 결국에는 대부분 많은 사람들이 꿈꾸는 미래가 대부분의 금융 활동이 온체인에 올라올 것이다. 이런 것들을 꿈꾸면서 빌딩하고 계신 분들이 많으리라고 생각해요. 그렇게 되면 급여도 월렛으로 받고, 카페 결제도 온체인 트랜잭션으로 하고, 월세도 내고, 나 에이브 같은 곳에서 자금 운용을 할 수 있는데 주소 하나만 알면 그 사람의 모든 걸 다 알 수 있게 된다면, 개인의 프라이버시 관점에서도 되게 안 좋은 것이고요.

그리고 만약에 기관이 온체인을 쓴다는 가정하에서, 예를 들어서 어떤 기업이 온체인으로 급여를 지급한다고 했을 때, 그게 온체인에 투명하게 다 공개되면 직원들끼리도 서로의 월급을 다 알 수도 있고, 그래서 되게 다양한 문제들이 존재하게 돼서, 저는 개인적으로 온체인 프라이버시 솔루션이 어쨌든 매스 어답션에 중요하다고 생각하고 있습니다. 그래서 저희가 작년 11월 정도에 온체인 프라이버시 솔루션을 만들자고 얘기하면서 어떤 솔루션을 만들 것인가 했을 때, 되게 다양한 요구사항들이 있었는데, 그중에 저희가 중요하게 봤던 것들은 크게 세 가지로

공유할 수 있을 것 같아요. 첫 번째는, 많은 프라이버시 솔루션들이 ZK, FHE, 암호학을 쓰면서 그런 연산들의 일부분을 사용자 클라이언트 사이드, 노트북이나 핸드폰에서 그런 연산들을 수행하게끔 만드는 경우가 되게 많은데, 그러면서 UX가 안 좋아지는 단점들이 있어서, 그런 단점이 있으면 안 된다고 생각을 하고요. 대표적인 이슈로, 예를 들어서 Railgun 같은 걸 써보신 분들은 아시겠지만 ZK 증명을 생성하는 데도 만약에 내 디바이스가 컴퓨팅 리소스가 딸린다 싶으면 몇 초에서 10초 이상 걸리는 경우도 있고, 또 하나 큰 문제가, Railgun 같은 경우는 잔고랑 전송 내역을 보기

위해서 블록체인을 쭉 스캔을 해야 돼요. 무슨 말이냐면, 내가 전송을 할 때마다 내 전송 정보, 내가 누구한테 얼마를 보내는지 이런 정보들이 내 뷰잉 키로 암호화돼서 블록체인에 올라간단 말이죠. 그래서 그거를 나중에 앱을 껐다가 다시 보려고 하면 그 정보를 블록체인에서 받아와서 그거를 로컬에서 디크립트를 해서 프론트엔드에 보여주는 그런 메커니즘이기 때문에, 그 에서 전송된 모든 내용들의 사이퍼텍스트를 하나하나 가져와서, 이게 내 건가 하고 디크립트를 해보면서 성공하면 내 거고 실패하면 아니다, 이런 식으로 계속 체인을 스캔하는 과정을 통해서 잔고를 가져왔다는 거죠.

그래서 그게 되게 불편하다고 느꼈고, 실제로 그게 로드에 몇 분 이상 걸린 경우가 많아서, 저희는 그런 솔루션이 어답션에 방해가 된다고 생각을 해서 빠를 것이 하나의 요소였고요. 두 번째는, 보통 프라이버시 프로토콜은 별도의 키 메커니즘을 가지고 있어서, 기존 월렛들이 아니라 새로운 키를 생성하고 니모닉을 저장하고 이런 과정들이 필요하기도 하고, 기존의 지갑들을 쓰지 못하거든요.

대표적으로 EOA뿐만 아니라 Safe나 MPC 같은 기관들이 많이 사용하는 지갑들을 그대로 플러그인해서 써야 된다는 생각이 있었고, 또 예를 들어서 그런 프라이버시 솔루션을 쓰더라도 새로운 유저를 온보딩하는 것이 아니라 기존 이더리움의 유저들, 기존 이더리움의 유동성에 접근할 수 있어야 한다고 생각했습니다. 마지막으로, 빠른 솔루션을 쓰면 결국 서버의 역할이 되게 중요하게 되는데, 이 서버의 역할이 중요함에도 불구하고 결국에는 자금에 대한 권한은 엔드 사용자에게 있어야 한다고 생각을 했어요.

그래서 서버가 아예 없어지는 아주 극단적인 상황에서도 사용자들이 자신의 돈은 자기가 출금할 수 있게끔 해야 한다고 생각을 했었습니다. 그래서 이런 접근 방식을 가지고 기존의 솔루션들을 리서치를 해봤을 때, 뭔가 하나씩 다 부족한 부분들이 있었던 것 같아요. 예를 들어서 세 가지 정도 예시를 가져왔는데, Railgun이나 Privacy Pools 같은 클라이언트 ZK 증명을 쓰는 경우에는 아까 말씀드렸듯이 속도가 문제입니다. 또 Aztec같이 전용 ZK, 어떤 프라이버시 체인을 구축하는 솔루션들은 당연히 프라이빗 트랜잭션에 맞게끔 그 모든 메커니즘이 짜여 있기는 하더라도, 기존의 유저들이나 기존의 유동성에

접근할 수 없다는 단점이 있었어요. 새로 유저와 유동성을 부트스트랩해야 하는 문제가 있었고, 요즘 떠오르는 어프로치가 FHE 기반 어프로치인데, FHE 메커니즘 자체가 ZK보다 거의 100배 느리거든요. 그래서 연산 자체가 무겁기도 하고 처리량이 딸리기도 하고, 이것도 역시 앱 로직을 새로 써야 하기 때문에 부트스트래핑 문제가 발생하게 됩니다. 저희는 ZK와 TEE를 결합해서 빠르면서도 셀프 커스터디가 지켜지고, 기존 유동성, 기존 유저들이 자연스럽게 쓸 수 있는 솔루션을 만들어보려고 했습니다.

저희가 지금 개발하고 있는 솔루션 이름은 Privacy Boost이고요. 이것에 대해서 간단하게 설명드리려고 합니다. 우선 Privacy Boost에 대해서 들어가기 전에, 풀 기반 프라이버시에 대해서 혹시 모르시는 분들이 있을 수도 있을 것 같아서 간단하게 설명을 해보도록 하려고 해요. 그래서 이 풀 기반 프라이버시는 Zcash나 Railgun, 좀 넓게 보면 토네이도 캐시, Privacy Pools 같은 솔루션에서도 다 사용되는 방식인데, 이거 같은 경우는 잔고를 표현할 때 UTXO 방식으로 사용됩니다.

EVM에서는 주소와 잔고의 매핑으로 스테이트를 표현하는데, 얘네 같은 경우에는 각 유저가 가진 UTXO 안에, UTXO 1번에는 이더리움 10개, 2번에는 USDC 10개, 이런 식으로 해서 각각의 UTXO 형태의 합으로 잔고를 표현하는 구조고요. UTXO 혹은 노트라고도 부르는데, 그 노트는 어떻게 구성되어 있냐면, 어떤 토큰을 얼마만큼 가지고 있는지, 그리고 누가 가지고 있는지 이런 것들을 해시해서, 그거를 UTXO 혹은 노트라고 부르게 됩니다.

그리고 그 노트들을 머클 트리 형태로 구성을 해서 루트만 온체인에 올리게 되고요. 그래서 이 머클 트리 형태로 구성된 이 스테이트 트리에서 내가 누군가한테 내 돈을 보내려고 한다면 어떤 식으로 상태 전환이 일어나냐면, 내 노트를 사용했다는 증표를 남기고, 그리고 수신자, 받는 사람한테 새로운 노트를 만들어 주는 방식으로 상태 전환이 이루어집니다. 이때 프라이버시가 어떻게 지켜지냐면, 일단은 일단은 노트마다, 한 노트마다 널리파이어라는 값이 고유한 값이 연결되어 있어요.

그래서 노트 1번에는 nullifier A, 2번에는 nullifier B, 이런 식으로 연결이 되어 있고, 그리고 ZK 서킷에서 내가 이 노트를 가지고 있음, 이 노트가 트리 안에 존재함을 증명하고, 그리고 한 가지 더 증명을 하는 것은 그 특정 노트와 내 nullifier의 연결성을 증명을 하게 됩니다. 이 두 가지를 특히 서킷 안에서 하기 때문에 프라이빗하게, 공개하지 않고 증명을 할 수 있게 되고, 공개되는 정보는 이 nullifier라는, 그 노트와 연결된 nullifier라는 정보만 온체인에 공개되게 돼요.

그러니까 nullifier가 무효화라는 뜻이니까, 특정 노트가 무효화됐으면 온체인에서 알 수 있지만, 어떤 노트가 무효화되는지, 그러니까 어떤 노트가 사용되었는지는 알 수 없는 거죠. 그리고 노트 무효화까지 했으면 트리 안에 받을 사람이 받을 노트랑 거스름돈과 거스름돈까지 추가를 하게 됩니다. 그래서 온체인에서는 새로 추가되는 노트랑 nullifier 몇 개 정도만 공개해도 돼요. 그러니까 누가 누구한테 얼마를 보냈는지 숨길 수 있는 것이죠.

저희는 이런 구조에서, 보통은 이 노트 사용 증명에 ZK를 쓰는데, 그 ZK를 보통은 사용자 디바이스에서 생성을 하거든요. 저희는 TEE를 사용해서 TEE 안에서 프라이빗하고 빠르게 ZK 증명을 생성하는 방식을 택했습니다. 그래서 서버가 ZK 증명을 생성하기 때문에 1초 내로 증명이 생성되고, 빠르게 세틀먼트가 이루어지고요. 그리고 사용자들이 체인을 스캔하지 않아도, TEE 안에 암호화된 형태로 누가 누구한테 얼마를 보냈는지 이런 것들이 저장이 되어 있기 때문에, 밸런스 API나 트랜스퍼 내역 API 이런 것들을 바로바로 제공할 수 있게 됩니다.

그리고 TEE를 쓰더라도 결국에는 이 상태 전환의 올바름이 ZK랑 컨트랙트에서 정의가 되기 때문에, 설사 TEE가 해킹이 되더라도 사용자의 자금을 TEE가 함부로 가져가거나 할 수 없는, 그런 관점을 가지고 있어요. 그래서 조금 더 깊게 들어가서 저희가 어떤 기술적 선택들을 했고, 그것의 장단점은 무엇인지 알아보려고 합니다. 저희는 일단 이 ZK 증명 알고리즘에 Groth16이라는, 되게 오래됐지만 클래식한 알고리즘을 사용하고 있어요.

사실 ZK 하면 요즘에 많이 등장하는 게 SP1이라든지 이런 ZK VM들이 되게 많이 언급이 되고, 이더리움에서도 실제로 zkVM의 검증을 클라이언트에 내장하려고 하고 있고, 롤업들에서도 되게 많이 쓰는 게 zkVM인데, 저희가 왜 이제 Groth16을 쓰게 되었느냐를 좀 설명드리려고 합니다. zkVM은 RISC-V 같은 범용 ISA를 빠르게, 병렬로 증명하는 데 최적화된 도구라고 보시면 되는데, 저희가 증명해야 하는 워크로드가 별거 없거든요.

저희가 주로 ZK 회로 안에서 하는 연산은 해시 연산이에요. 머클 증명을 검증한다든지. 그래서 결국에는 ZK-friendly 해시를 그냥 서킷에서 검증하는 거다 보니까, EVM 같은 헤비한 로드에는 zkVM이 더 어울릴지 몰라도, 저희 같은 경우에는 zkVM이 가진 어떤 오버헤드들, 예를 들어서, STARK 프루프를 온체인 검증 가능한 형태로 래핑한다든가, 혹은 STARK 프루프가 크기가 되게 크거든요.

몇백 킬로바이트 단위라서 그걸 압축하는 데 드는 오버헤드라든가, 이런 것들을 굳이 감수할 필요가 있을까? 라는 생각을 해서 훨씬 더 빠른 Groth16을 택했던 것 같고요. 다른 Halo 2나 Noir 같은 SNARK 패밀리도 Groth16, 즉, zkVM보다는 훨씬 더 오버헤드가 적었고, EVM에서 증명하는 데 코스트가 덜 드는 좋은 솔루션들이기는 하지만, Halo 2 같은 경우에는 구현의 복잡성 이런 이슈가 있었고, Noir 같은 경우에는 올해 초에 검토를 했는데, 그때 당시에는 Noir 프루프의 온체인 증명 검증 비용이 거의 2 million 가스 정도 됐거든요.

지금은 많이 개선된 걸로 아는데, 그때는 당시에는 되게 비싸서 결국은 Groth16을 선택하게 됐습니다. 근데 Groth16을 선택하면 대가가 뭐냐면, 특히 회로의 로직을 바꿀 때마다 trusted setup이라는 것을 해야 돼요. 그래서 증명을 생성하는 데 필요한 어떤 랜덤 값을 여러 명이서 생성을 해서, 그래서 이게 이 랜덤 값을 누군가 혼자 생성해버리면 이 값으로 증명을 조작할 수 있는, 그런 가능성이 존재하거든요. 그래서 그런 걸 방지하기 위해서 여러 명이서 같이 생성을 해서, 한 명만 이제 어니스트해도 괜찮다, 이런 메커니즘인데, 그런 과정들을 저희가 프로토콜 업그레이드를 할 때마다 거쳐줘야 돼서,

그런 거에 대한 비용이라든지, trusted setup을 해달라는 것, 주변 사람들한테 그렇게 요청하는 비용이라든지, 그런 서버를 운영해야 하는 것이라든지, 이런 관점이 있게 되었습니다. 그리고 저희가 두 번째로 중요하게 생각했던 것은, 저희가 TEE 안에서 ZK 증명을 생성하고 거기서 잔고나 이런 것들을 암호화된 형태로 운용하는 형태인데, 이게 아예 없어져도 컨트랙트에서 사용자가 자금을 꺼낼 수 있게, 어떻게 보면 L2 개념에 좀 익숙하신 분들은 escape hatch라는 것들을 들어보셨을 텐데, 얘도 시퀀서가 없어져도 L2에서 자금을 꺼낼 수 있게 하는 메커니즘이거든요.

그거랑 되게 유사하게 메커니즘을 짰습니다. 그래서 저희 Privacy Boost에서 돈을 보낼 때마다 누구한테 얼마를 보냈냐 이런 정보들을 사용자의 뷰잉 키로 암호화를 해서 온체인에 올려놓고, 나중에 TEE 서버가 없어져서 forced withdrawal을 해야 될 때, 그 암호문들을 다 하나씩 스캐닝해서 디크립트해서 내 잔고가 얼마 있고 내가 얼마를 뺄 수 있구나, 이런 것들을 확인을 한 다음에 직접 ZK 증명을 생성해서 컨트랙트에 직접 보내는 형태로 forced withdrawal을 가능하게끔 설계를 해놨습니다.

그리고 이 세 번째는, 어떻게 보면 저희 Privacy Boost만의 Account Abstraction, 계정 추상화라고 볼 수 있을 것 같은데요. 기존에, 아까 노트 얘기로 돌아와서, 이 노트가 얼마의 토큰, 얼마의 금액, 그리고 여기에 주인이라는 값이 들어있잖아요. 이 노트가 누구의 소유인가. 보통 프라이버시 프로토콜들은 이 주인이라고 적힌 이 값에다가 스펜딩 키의 퍼블릭 키를 넣거든요.

그러다 보니까 노트랑 스펜딩 키가 되게 강하게 결합된 구조예요. 그러니까 만약에 내가 스펜딩 키를 잃어버렸다거나, 혹은 스펜딩 키가 뭔가 보안이 노출된 것 같아서 교체하고 싶다거나 했을 때, 마이그레이션 코스트가 되게 많이 들고요. 이 노트를 전부 다 다시 써야 되는 거니까, 다른 계정으로 보내야 되는 거니까. 그렇기도 하고, 예를 들어서 Safe나 MPC 지갑같이 보안상의 이유로 키를 분산해놓는 프로토콜 같은 경우에는, 프라이버시 프로토콜의 경우 지출 키가 하나다 보니까 이걸 그대로 쓸 수가 없는 거예요. 그러니까 이걸 프라이버시 프로토콜에서 Safe나 이런 애들이 쓰려면

별도의 스펜딩 키 자체를 쪼개서 나눠서 MPC로 서명을 생성하고, 이런 별도의 프로토콜과 인터페이스가 필요하게 됩니다. 그래서 이것이 큰 코스트라고 생각했고요. 그래서 저희는 노트와 계정을 연결하는 방식을 조금 바꿨습니다. 노트 안에 들어가 있는 주인이라는 값이 지출 키의 퍼블릭 키가 아니라 계정 ID이고요. 그리고 그 계정 ID가 Auth Registry라는 곳에서 다양한 형태의 계정과 연결되는 형태입니다.

그래서 이 계정 ID가 EOA에 속할 수도 있고, 어떤 스마트 어카운트에 속할 수도 있고, Safe 계정에 속할 수도 있고, MPC 월렛에 속할 수도 있는 것이죠. 그래서 그런 형태로 해서, 뭔가 저희가 계정을 표현하는 방법을 좀 더 다양화하고, 뭔가 기존 계정과 좀 호환성을 갖추려고 선택한 방식입니다. 요거 같은 경우는 나중에 이제 저희가 만든 어떤 기능과 연결되는 부분이 있고, 단점으로는 프루빙 코스트가 좀 늘어나는 단점이 있는 것 같아요. 이 Auth Registry도 머클 트리 형태로 구성해서 ZK 증명 안에서 증명이 되어야 하는 부분이다 보니까, 프루빙 코스트가 소폭 증가하는 정도의 단점이 존재하는 것 같습니다.

그래서 저희가 3월에 처음에 이 Privacy Boost를 출시를 했고, 8월 정도에 v2 기능들이 출시가 됐는데, 이것에 대해서 간단하게 설명을 드려보도록 할게요. 아까 말씀드렸던 Auth Registry 관련된 피처로 저희가 멀티시그랑 MPC 지원을 추가하게 되었습니다. 아까 말씀드렸듯이 기존 프라이버시 프로토콜 같은 경우에는 Safe 지갑을 쓰려면 키를 분산시키는 인프라가 필요하다고 했었는데, 저희는 그런 게 추가되면 그 자체로 보안 리스크라고 생각을 했고, 그거는 더 이상 Safe가 아니라 별도의 MPC

프로토콜을 쓰는 것 같다고 생각을 했거든요. 저희가 만든 Safe나 MPC 지원은, Safe나 MPC 기존 인프라를 그대로 사용하면서도 쓸 수 있게 만들었습니다. 그래서 어떻게 만들었냐면, Safe가 직접 Auth Registry라는 곳에다가 리프 형태로, 내가 얼만큼 누군가한테 보낼 거야, 이런 정보를 해시로 난독화를 해서 추가를 하게 됩니다. 그게 일종의, 어떻게 보면, 이 Privacy Boost에 Safe의 권한으로 승인된 어떤 일회용 세션을 주는 거죠.

그래서 그렇게 Auth Registry에 추가된 전송 정보를 서버가 대조를 한 다음에, 그거에 맞게 스테이트 트랜지션 처리하고 ZK 프루프로 검증하는, 그런 형태로 이제 Safe가 Privacy Boost와 상호작용을 할 수 있게 됩니다. 저희가 노트와 지출 키를 분리했기 때문에 Safe가 서명해서 보내는 일회용 세션이 Privacy Boost 안에서 가능하게 되는 것이죠.

단점으로는, Safe가 트랜잭션을 보낼 때마다 Auth Registry에 특정 리프를 온체인에서 직접 추가하는 방식이다 보니까, Safe가 Privacy Boost와 인터랙션을 했구나, 정도는 보여요. 완전히 다 프라이빗한 것입니다. 대신에 특정 커밋먼트가 해시로 난독화되어 있다 보니까 그게 어떤 내용인지, 누가 얼마 보낸다든지 이런 것들은 보이지 않는 형태입니다. 실제로 저희 사이트에서 Safe나 Fireblocks 같은 게 사용할 수 있습니다.

두 번째는, 이건 좀 다른 이야기인데, 저희가 바이낸스 같은 거래소를 사용하면 입금 주소가 존재하잖아요. 그런 개념을 차용해서 저희도 입금 주소를 최근에 만들었습니다. 그래서 사용자 소유의 EOA를 만들고, 거기에 ERC-20 보내시면 자동으로 Privacy Boost 안으로 쉴딩이 되도록 설계된 코드를 설치합니다. 그래서 그 EOA를 생성하고, 그 주소에 ERC-20이나 이더를 보내면 자동으로 내 Privacy Boost 계정으로

입금이 되는 그런 형태입니다. 이거 같은 경우는 저희가 이것은 Privacy Boost에 대한 입금을 좀 더 쉽게 만들기 위해서, 거래소처럼 쉽게 만들기 위해서 짠 피처를 만들었습니다. 여기에서는 결국에는 입금하는 토큰이나 금액 같은 건 공개가 되지만, 그게 어떤 Privacy Boost 계정으로 입금되는지는 숨겨지는 구조입니다. 그리고 마지막으로 저희가 새로 만든 피처 중에 하나가 게이트웨이라는 피처인데, Privacy Boost 안에 입금을 해놓은 그 자금을 가지고 외부 디파이,

외부 기존에 존재하는, 예를 들어서 모포라든지 유니스왑 같은 그런 디파이 프로토콜과 인터랙션을 할 수 있게 만들어 놓은 피처예요. 그래서 기술적으로는 Privacy Boost 밖으로 출금을 해서, 그 출금한 돈이 디파이 프로토콜과 인터랙션을 해서, 예를 들어서 볼트면은 에셋을 넣고 share를 받고, 혹은 스왑이면은 이더를 넣고 그리고 USDC를 받고 해서, 그 나온 결과 토큰을 다시 Privacy Boost 안으로 입금하는 그런 구조가 되어 있습니다.

그래서 이것 같은 경우는, 이게 좀 잘못 적혀 있는 것 같은데, 어떤 디파이 프로토콜과 얼마를 보내고 이런 것들, 그런 디파이 프로토콜과 인터랙션한 토큰과 어마운트 자체는 보이지만, 그 돈이 어떤 분의 어떤 출처에서 나왔고, 누가 그 액션을 수행을 했고, 그리고 나중에 어디에 쓰였는지 이런 것들은 숨겨질 수 있게 되는 그런 구조입니다. 이런 것들은 실제로 저희가 지금 베이스 메인넷, OP 메인넷 이런 데에 라이브되어 있고, 이거를 써서 이제 자금을 운용하는 분들도 계시는 걸로 보여요.

누가 운용하시는지 저도 모르겠지만. 그래서 정리를 하자면, 저희는 기존 이더리움 자산, EVM 자산과 지갑을 그대로 쓰고 싶은 경우에 맞게 설계를 해놨고, 빠른 거에 초점을 맞춰서 전송 한 건에 500ms 이하의 레이턴시를 지향하고 있고요. 실제로 그 정도 수준의 레이턴시이고, 그리고 어쨌든 TEE를 기반으로 프라이버시를 보장하다 보니까 그...

특정 접근 권한 같은 것들을 프로그래머블하게 설정할 수 있어서, 감사 가능한, 좀 더 프라이버시가 필요하다, 그런 경우에 좀 유용하다고 볼 수 있고요. 물론 사실 완벽한 프라이버시 솔루션은 없다고 생각해서, 앱의 로직 전체가 다 프라이버시해야 된다거나, 아니면 나는 서버가 특정 내 정보를 건드는 것조차도 싫다, 이러면은 뭐 Railgun 같은 클라이언트 프루빙을 사용하는 솔루션을 써야 될 것 같고, FHE를 이용하는 경우도 당연히 있을 거고요.

그래서 어쨌든 그런 트레이드오프들이 있는 것 같습니다. 저희는 다오 트레저리나 온체인 결제나 디파이와의 통합될 수 있는 솔루션을 지향하고 있습니다. 발표는 여기까지입니다. 질문 있으시면 질문해주시면 감사하겠습니다. 네. 그러니까 그게, 제가 그림이 조금 설명이 부족했던 것 같은데, 그 사용자가

이미 Privacy Boost에 있는 자금도, 그 자금을 뭔가 디파이에 쓰고 싶다 하면, 서버에 나는 이 자금을 뭐 하는 이런 것들을 보내게 됩니다. 그러면 서버가 그 요청을 처리를, 그 TEE 안에서 ZK 증명을 생성을 해서 그 자금을, 사용자의 자금을 꺼내서 출금 처리를 한 다음에, 게이트웨이로 출금 처리를 한 다음에, 그 게이트웨이에서 모포 볼트나 유니스왑 라우터 등과 인터랙션을 하고, 그 자금이 다시 Privacy Boost 풀에 재입금이 되는 구조라고 봐주시면 될 것 같습니다.

사용자는 프라이빗 게이트웨이 앱 같은 인터페이스가 있는 건가요? 아니면 기존에, 원래 프라이빗 게이트웨이에 돈을 넣고, 그 다음에 제가 프라이빗 게이트웨이 안에 있는 돈을 제가 이런 액션을 하고 싶다는 건 어디에 해야 되는지. 그런 사용자의 의도, 이런 것들은 다 서버와의 요청을 통해서 서버가 대신 처리해주는 그런 구조거든요.

프라이버시를 지키려면 사용자가 직접 요청을 하면 안 되다 보니까, 그래서 요청은 다 서버와 이루어진다고 보시면 될 것 같고, 그리고 아마 저희 앱을 직접 써보시면 아시겠지만, 기존 디파이를 쓰는 것과 유사한 인터페이스를 짤 수 있어요. 그래서 내부적으로 저희 SDK가 있어서, 그 안에서 서버와의 인터랙션을 추상화해서 제공을 하다 보니까, 저희 앱을 쓰지 않더라도 다른 월렛이나 앱이 Privacy Boost를 쓰고 싶다면 SDK를 프론트엔드 통합을 하시면 쓰실 수 있을 것 같습니다.

네, 발표 잘 들었습니다. 저도 아직 완벽하게 Privacy Boost를 기술적인 이해를 못하고 질문하는 걸 수도 있는데요. 그렇게 되면 이거 같은 경우에는 UX적으로 굉장히 편리성이 다른 대체 프로토콜이라든가 프로젝트보다 좋은 것 같아요. 또 반대로 궁금한 거는, 그러면 escape hatch 같은 거는 사실 TEE에 의존하지 않고도 가능한데, 실제로 사용한다거나, 아니면 쉴딩이라든지 프로토콜에 들어갈 때는 무조건 TEE 서버가 있어야 하는 건가요?

네, 그런 형태로 구성을 해놨고, 기본적인 전제는, 라이브니스 가정은 다 TEE 안에 있어요. 서비스가 정상적으로 운영되려면 TEE 서버가 필요하고요. 입금 처리라든지, 안에서 내부 전송이라든지 이런 것들은 다 TEE가, TEE만 처리해줄 수 있게 일단은 짜여져 있습니다. 아마 흔히 질문받아 보셨을 것 같은데, 싱글 포인트 오브 페일러에 대한 어떤 대책이나 그런 인프라나 구축이 되어 있는 건가요? 저희가 내부적으로는 다 HA라든지, 멀티 리전 인프라라든지 이런 것들을 구축을 해놓고 있기는 해요.

어쨌든 이게 그래서 그런 인프라들을 기반으로 해서 저희가 최대한 싱글 포인트 오브 페일러가 안 되게끔 노력을 하고 있기는 합니다. 마지막으로 게이트웨이 같은 경우는 결국에 게이트웨이의 TEE 환경 안에서 용어가 생각났는데, 만약에 오더를 날렸을 때 TEE가 저걸 받아가지고, 시스템이 받아가지고 저걸 처리하고 실행해주는 거면, 중간에 예를 들면 이게 아토믹하게 처리된다는 보장을

받을 수가 있나요? 그러니까 중간에 만약에 거래가 끊긴다거나, 아니면 잘못됐을 때 원하는 오더대로 처리가 안 돼서 quote대로 안 되는 경우가 생길 수 있습니까? quote대로 안 되는 경우는 생길 수도 있어요. 왜냐하면 어쨌든 요청을 하는 시점과 ZK 프루프를 생성하고 그걸 제출하는 시점이 다르다 보니까, 이게 뭐 슬리피지나 이런 것들이 타이트하면 실패하는 환경이 생길 수 있고요. 그렇게 됐을 때 저희는 다시 실패의 유효성에 대해서는 그 가 있어서 다시 실패한 원금을 Privacy Boost 안에 쉴딩하는 그런 메커니즘을 가지고 있고요.

그리고 그거 외에는 사실 이 전체 과정이, 출금하고 그 디파이 프로토콜과의 인터랙션하고 다시 하는 모든 과정이 다 아토믹해서, 그거 외에는 저는 따로 문제될 부분은 딱히, TEE가 시뮬레이션만 잘 해준다면 괜찮을 거라고 생각합니다. 감사합니다.

그래서 지금 다음에 또 모더레이터로 돼서, 여기까지 하겠습니다. 감사합니다.