Brave 브라우저

작년 말, 크롬이 느리다(루머로 추정)라는 말을 듣고, 브라우저 대안을 찾던 중 Brave를 발견하였습니다. 클릭 몇 번으로 크롬의 모든 북마크, 플러그인 등이 Brave 브라우저로 들어와 큰 불편함 없이 브라우저를 갈아타게 되었습니다.

 

당시에는 갑작스런 위화감에 브라우저를 바꾸게 되었으나, Brave 블로그를 살펴볼 수록 Brave가 가지고 있는 고유한 특성이 '데이터 엔지니어'와 연관된 사항에서 호기심을 자극하여 꾸준히 살펴보게 되었습니다.

 

Brave는 JavaScript 창시자(Brendan Eich)가 CEO라는 사실 외에도, (제가 관심있던) fingerprinting block과 같은 privacy-aware [1], block chain [2]과 off-line ML model training [3]라는 궁금증을 불러일으키는 기술들이 사용되었습니다. 그리고 데이터 엔지니어로 게걸스럽게(?) 데이터를 저장해야한다는 관점이 지배적이었던 제 생각과는 매우 다른 claim을 보면서, 어떤 관점으로 상품을 개발해나가고 있는지 더 확인을 안해볼 수 없었습니다.

 

이 글에서는 Brave 브라우저와 관련해 위와 같은 기술들을 중점적으로 살펴보겠습니다.

 

• Privacy - 어떻게 Brave는 Privacy를 보호하는지
• Decentralized Ad Platform - THEMIS
• IPFS 지원

 

관련글:

• Basic Attention Token이란?

 

---

Privacy as a first-class feature

Brave 브라우저는 6개의 브라우저(Google Chrome, Mozilla Firefox, Apple Safari, Brave Browser, Microsoft Edge, Yandex Browser) 를 대상으로한 연구에서 privacy 관점에서 가장 높은 점수를 기록하였습니다 [5]. 

 

Blocking Goals and Policy

Privacy를 위해 Brave 브라우저에서는 어떻게 웹사이트가 실행되고, 어떤 네트워크 요청을 웹사이트가 할 수 있는지 막거나 변형합니다. 그 부분의 주요 목적과 정책은 다음과 같습니다 [4]:

 

• 제3자 광고의 tracking block: 제3자 광고와 관련해 Brave의 목적은 광고 이미지와 같은 광고 자체를 막는 것이 아닌, 그러한 광고가 야기하는 tracking을 막는 것입니다. 제3자 광고와 tracking을 분리하는 것은 거의 불가능할 정도로 어렵기에, 2개 모두 block하게 됩니다. 의도적으로 first-party 광고를 막는 것을 목표로하지는 않으나, block되었을 때 그것을 오류로 판단하지도 않습니다. 

 

• browser fingerprinting block: 유사하게 Brave는 기기의 고유한 특성을 통해 유저를 식별하려는 코드를 막습니다. 그러한 식별 기술은 전통적인 쿠키 기반의 트래킹과 같이 해롭습니다.

 

• harmful website block: 또한, Brave는 crypto-mining script와 같이 해로운 사이트의 해로운 행동을 막습니다. 

Blocking Techniques and Methods

Brave는 위와 같은 정책을 단계별로 실현하기 위해서  많은 방법과 기술을 사용합니다. 아래에 기술된 방법 대부분은 Brave 브라우저의 "Shields" 패널을 통해 컨트롤할 수 있습니다. 플랫폼의 제약으로 일부 방법은 iOS에서 제외되었습니다.

 

첫 번째로, Brave는 가장 흔한 트래킹 메커니즘인 제3자 쿠키 송신을 막습니다. 디폴트로, Brave는 절대 제3자에 쿠키를 송신하지 않고, 제3자 컨택스트 상의 storage setting이나 script의 reading 실행을 무시합니다. 

 

두 번째로, Brave는 cross origin 요청 시 referrer header를 변경합니다. Cross-domain이 아니라 마치 해당 요청이 same domain에서 요청된 것으로 만들어 referrer 추적을 막습니다.

 

세 번째로, 제3자 frame이 passive fingerprinting 기술을 통해 사용자를 트래킹하지 못하도록 막습니다. Brave는 사용자 식별에 사용될 수 있는 Web API 실행 시 변형(Farbled: slightly randomizing the output of semi-identifying browser features)된 값을 리턴합니다. 

 

Farbling의 레벨은 3단계(Off, Default, Maximum)의 단계로 조절되며, Farbled되는 대상 API Endpoints는 아래와 같습니다 [6]:

JavaScript Interface	Endpoint(s)	GitHub Issue
CanvasRendering2dContext	getImageData	9186
	measureText isPointInPath isPointInStroke	9186
HTMLCanvasElement	toDataURL toBlob	9186
OffscreenCanvas	convertToBlob	9186
MediaDevices	enumerateDevices	8666
WebGL2RenderingContextBase	getBufferSubData copyBufferSubData	9189
	getParameter	9188
WebGLRenderingContext	getFramebufferAttachmentParameter getActiveAttrib getActiveUniform getAttribLocation getBufferParameter getExtension getFrameBufferAttachmentParameter getProgramParameter getRenderBufferParameter getShaderParameter getShaderPrecisionFormat getTexParameter getUniformLocation getVertexAttribOffset readPixels	9188
WEBGL_debug_renderer_info	UNMASKED_VENDOR_WEBGL UNMASKED_RENDERER_WEBGL	9188
NavigatorPlugins	plugins	9435
AnalyserNode	getByteTimeDomainData getFloatTimeDomainData getByteFrequencyData getFloatFrequencyData	9187
AudioBuffer	getChannelData copyFromChannel	9187
NavigatorID	userAgent	9190
XRSystem	isSessionSupported	9193

 

네 번째로, Brave는 다양한 커뮤니티에서 개발된 광고 또는 트래킹 사이트의 리스트를 가져와 사용합니다. 이것에는 EasyList와 EasyPrivacy, uBlock Origin 또는 Disconnect 프로젝트에서 생성된 리스트, 그리고 Brave가 직접 관리하는 리스트들 등이 포함됩니다. 이러한 리스트에 표기된 URLs은 block되거나 resource를 브라우저가 변형하여 사용자를 보호합니다. 사용되는 필터 리스트는 프로젝트 Github에 공유되어 있습니다.

 

다섯 번째로, Brave는 HTTPSEverywhere에서 생성된 리스트를 사용하여 HTTPS 연결되 업그레이드 될 수 있는 URLs를 식별하고 자동으로 업그레이드하여 사용자의 데이터를 보호합니다.

 

여섯 번째로, Brave는 제3자의 CNAME Cloaking을 판별하여 트래킹을 막습니다. 원래의 CNAME DNS는 "다른 이름으로 부르되, 특정한 것으로 처리되게" 해줍니다. 예로 Github Pages가 pes10k.github.io의 도메인을 제공했다면 CNAME instruction을 통해 방문자는 www.peteresnyder.com로 위의 github 사이트에 접근할 수 있습니다. 

 

일부 트래커들은 privacy 방어를 피하기 위해 CNAME 레코드를 악용합니다. 대부분의 privacy 도구가 "first-party"인지 "third-party"인지 구분하는 데에 초점을 두고 있기에, 실제 제3자 트래킹 코드가 CNAME 변형을 통해 "first-party"처럼 보이게 하는 것입니다.

 

일곱 번째로, Brave는 Privacy를 보호하는 동시에 제3자 스크립트가 실패하여 사이트가 실패하는 것을 막기 위해 "ephemeral site storage"를 제공합니다. 제3자 프레임들은 DOM storage APIs를 위해서 임시적인 partitioned된 storage를 제공받습니다. 그리고 마지막  first-party 문서가 닫히면 제3자 storage 파티션은 모두 비워집니다(브라우저 restart 시에는 모든 파티션 비워짐).  

 

Storage Access API와의 연동이나 iframe navigation 시 partitioned cookie 송신, DOM Storage APIs 추가 등을 추가 고려하고 있습니다.

 

추가적으로 웹 문서의 변형, 네트워크 요청, 스크립트 실행, privacy 연관 Web API 접근 등의 탐지를 개선하기 위해 PageGraph를 연구 진행하고 있습니다 (AdGraph와 유사).

 

Decentralized Ad Platform - THEMIS

온라인 광고는 인터넷을 무료로 제공할 수 있는 동력이 됩니다. 사용자는 무료로 거의 모든 웹사이트를 방문할 수 있지만, 그 대신 privacy라는 비용을 치루고 사용자의 데이터와 광고비를 먹어치우는 제3자 또는 중간자(intermediaries)를 맹목적으로 허용하여야 합니다. 이로 인해 많은 사용자가 ad blockers를 사용해 광고를 막고 광고주는 많은 비용을 광고비로 소모하고 있습니다. 

 

현존하는 privacy-preserving 접근법(Adnostic, Privad, Brave Ads)은 광고주에게 전달되는 광고 성능 분석의 무결성을 보장하지 못하고, audit 없이 사용자가 신뢰해야 하는 centralized 관리에 의존하고 있습니다. 

 

THEMIS는 decentralized 광고 플랫폼으로 1) 모든 참여자에게 auditability를 제공하고, 2) 광고 소비에 대한 댓가로 사용자에게 보상을 하며, 3) 광고주가 광고 캠페인에 대한 성능과 지불 리포트를 검증할 수 있도록 해줍니다 [7]. 

 

A high-level visual overview of the progressive decentralization steps of THEMIS - Image from [8]

 

기반 기술

이 장에서는 THEMIS 전반에서 사용되는 기술을 왜 그리고 어떻게 THEMIS가 사용하는지 다룹니다.

 

Proof of Authority Blockchains

THEMIS는 decentralized ad platform을 제공하기 위해 smart contract 기능이 있는 블록체인에 의존합니다. Smart contracts는 central authority 없이 모든 payments를 수행할 수 있도록 합니다. Ethereum Mainnet은 그러한 smart contact 기반의 유명한 사례 중 하나입니다. 그러나, 낮은 transaction throughput과 high gas costs, 그리고 낮은 확장성으로 인해 THEMIS에서는 Proof-of-Authority (PoA) 블록체인을 사용합니다.

 

컨센서스 프로토콜은 분산 시스템의 기초를 구성합니다. 어떤 컨센서스 메커니즘을 사용할지 결정하는 것은 분산 시스템에 기반한 서비스의 특성, 확장성, 가정에 영향을 미칩니다. PoA 블록체인은 권한이 주어진 validator nodes 풀을 통해 이뤄지는 컨센서스에 의존하는 분산된 ledger로 구성되어 있습니다. PoA validators는 IBFT/IBFT2.0, Clique와 같은 fast 컨센서스 프로토콜을 사용할 수 있으며 그를 통해 faster minted blocks를 얻어 PoA는 전통적인 PoW와 비교 시 더 높은 throughput을 이룰 수 있습니다. 전통적이고 permissionless 블록체인(Bitcoin, Ethereum 등)과 비교 시, 컨센서스에 참여하는 노드의 수가 적고 모든 노드는 인증되어야 합니다. THEMIS에서 validators 세트는 publishers나 foundations로 구성됩니다.

 

Private input transactions

THEMIS는 광고주의 privacy를 보호하기 위해서 private input transactions를 사용합니다. 좀 더 정확히는, THEMIS는 Quorum PoA sidechain에 의해 정의돈 private input transactions을 사용합니다. Smart contracts에 private input transactions을 제공하기 위해서는 input이 모든 validators의 public key로 encrypted되어야 합니다. Input과 output 모두 validators의 public key로 encrypt함으로써, 인자들은 public information의 reader로 부터 private한 반면에 validators 노드들은 값을 decrypt할 수 있고 컨센서스를 이루기 위해 smart contracts를 정확하게 실행할 수 있습니다. Quorum, Hyperledger Besu는 Ethereum 기반의 분산형 ledger 구현체로 private input 및 output transaction을 구현합니다.

 

Cryptographic Tools

Confidentiality

THEMIS는 각 사용자의 reward payouts(광고소비보상)를 계산하는 동시에 사용자 행동을 private하게 유지하기 위해서 추가적으로 homomorphic encryption를 사용합니다. Public-private key-pair(pk, sk)가 주어졌을 때, encryption은 3가지 함수를 통해 진행됩니다: 

 

• C = Enc(pk, M) : public key와 message가 주어졌을 때 ciphertext(C)를 리턴하는 encryption 함수 
• M = Dec(sk, C) : ciphertext와 private key가 주어졌을 때 message(M)를 리턴하는 decryption 함수
• S = Sign(sk, M) : message와 secret key가 주어졌을 때 Message의 signature(S)을 리턴하는 signing 함수

추가적인 homomorphic 특성은 2개의 ciphertexts(C1 = Enc(pk, M1), C2 = Enc(pk, M2))를 추가할 수 있도록하여 메시지에 encryption을 더합니다: C1 + C2 = Enc(pk, M1) + Enc(pk, M2) = Enc(pk, M1+M2).

 

그러한 encryption 알고리즘의 예로는 ElGamal과 Paillier encryption입니다. 

 

Integrity

정확한 decryption을 입증하기 위해서 THEMIS는 zero knowledge proofs (ZPKs)를 사용합니다. ZPKs는 한 객체(prover)가 private input에 대해서 특정 statement가 true라는 것을 다른 객체(verifier)에게 입증할 수 있도록 합니다. 이러한 입증은 statement가 true 또는 false인 사실 이외에는 다른 정보를 노출하지 않습니다. 또한 ZKPs를 통해 THEMIS는 integrity와 privacy를 보존하면서도 클라이언트 측의 컴퓨팅을 줄입니다. 

 

좀 더 정확히는, 사용자는 벌어들인 reward payout을 decrypt하고 decryption이 정확하다는 것을 증명합니다. 

 

Distribution of trust

THEMIS는 민감한 사용자 정보는 encrypted된 상황에서 각 ad 캠페인을 위한 public-private key-pair를 생성하기 위해서 trust를 분산합니다. Distributed key generation(DKG) 프로토콜을 사용해서 참가자 그룹이 분산되어 key-pair(pk, sk)를 생성할 수 있도록 합니다: 각 참가자는 일부분의 private key, sk(i)를 가지고 어떠한 참가자도 모든 private key, sk 정보를 알 수 없습니다. 

 

그 결과 key-pair는 k - n threshold key-pair로 decryption이나 signing 프로토콜 과정에서 n개의 참가자 중 최소한 k개의 참가자와 연동되어야 합니다. 그러한 과정은 동기 및 비동기 형태가 존재합니다. THEMIS 구현에서는 참가자 숫자가 적고 참가자가 key 생성 과정 동안 online이도록 유도되기에 동기 방식으로 충분합니다. 그러므로 THEMIS에서는 키 생성과 decryption 과정에서  [9]의 프로토콜을 따랐습니다.

 

분산된 환경에서 이러한 선택된 key 생성 참가자 그룹을 고르기 위해서 THEMIS는 verifiable random functions (VRFs)을 사용합니다. 일반적으로 VRFs는 사용자가 랜덤 숫자를 발생시키고 랜덤임을 증명할 수 있도록 합니다. 그러한 특성을 이용해 랜덤으로 구성된 사용자 풀을 선택하고 분산된 key를 생성합니다. Public-private key-pair(VRF.pk, VRF.sk)가 주어졌을 때, VRFs는 한 가지 함수로 정의됩니다: 랜덤숫자를 발생시키는 VRF.Rand와 proof of correct generation을 리턴하는 VRF.RandGen.

 

Image from [7]

Confidential payments for account-based blockchains

Account 기반의 블록체인에서 confidential payments는 accounts 간의 asset 송수신을 송수신 양이나 account의 잔액을 노출하지 않으며 진행될 수 있도록 합니다. 추가적으로, 송신자는 payment의 정확성을 검증할 수 있습니다(예로, 2번 중복 지출되는 것 등).

 

Confidential payments는 학계 그리고 산업계에서 최근 많은 관심을 받았습니다. THEMIS 개발 시, AZTEC과 Zether 2가지 솔루션을 고려하였습니다. 

 

AZTEC 프로토콜은 Ethereum virtual machine에 기반한 confidential asset 구축을 위한 smart contracts 도구를 구현하였습니다. AZTEC 프로토콜은 asset transaction의 잔액을 노출하지 않고 transaction을 검증하기 위하여 commitment scheme과 zero-knowledge proofs를 정의하였습니다. AZTEC의 중요한 기능은 여러 개의 payments의 비용을 배치 형태로 amortize하는 정확한 payment 증빙을 prover가 생성하는 것을 가능하게한 것입니다.

 

Zether 프로토콜은 Sigma-Bulletproofs와 one-out-of-many proofs를 사용하여 account 기반의 블록체인에서 confidential하고 익명의 payments가 가능하도록 하였습니다. Zether는 배치형태의 payment proof validation을 제공하지 않기 때문에 payments 수가 늘어나는 것에 linear하게 소요시간이 증가합니다. 

 

위와 같은 소요시간의 한계를 고려하여, THEMIS는 AZTEC을 사용하였고, 월 50.9 백만의 payments까지 확장할 수 있게 되었습니다.

 

System Overview

이 부분에서는 THEMIS 시스템을 상세히 기술합니다 (기본 형태인 Straw-man THEMIS를 제외하였습니다).

 

기본적인 가정은 사용자가 web browser를 통해 THEMIS와 통신하는 것(mobile도 똑같은 형태로 가능), 그리고 privacy-preserving ad personalization과 광고소비에 대하 incentives가 광고 플랫폼 내에 존재하는 것입니다:

 

 

Privacy-preserving Ad Personalization

privacy-preserving 광고 개인화를 위해서 THEMIS는 2019년 이후 지속적으로 운영된 Adnostic이나 Brave Ads와 같은 관점을 고수합니다. 하지만 중앙집중형 Campaign Manager 대신, THEMIS에서는 Campaigns Facilitator(CF)를 만들어 광고주가 선호하는 CF를 선택할 수 있도록 합니다. Ad catalog는 모든 active 캠페인의 데이터와 메타데이터를 가지고 있습니다. 

 

Ad-matching은 pretrained 모델에 기반해 로컬에서 일어나게 되며 사용자의 관심과 웹 브라우징 히스토리는 [10], [11]과 유사하게 추출됩니다. 어떠한 데이터도 사용자의 기기를 벗어나지 않기 때문에, 가장 잘 매칭되는 광고 추천에 사용되며 사용자의 privacy도 보호할 수 있습니다. 

 

Prefetching 광고에 대한 아이디어는 새로운 것은 아닙니다 [12], [13]. 한 연구에서는 스마트폰 사용자를 위해 광고를 pre-fetching하는 것은 실제 구현 상의 조건을 충족시켜줄 뿐만 아니라 광고 transaction으로 인한 에너지 소비를 50% 가까이 줄여준다는 사실을 발견하였습니다.

 

Incentives for Ad-viewing

THEMIS는 ad 소비에 대한 댓가로 보상을 제공하며 광고 소비를 유도합니다. 학계 또는 산업계의 다른 제품들 역시 그러한 사용자 보상 구조를 사용하고 있습니다. THEMIS에서는 광고에 대한 각 view/click은 금전, crypto-coin, 쿠폰 등의 형태의 보상을 돌려줍니다. 광고마다 보상의 양이 다르며, 그러한 보상의 양은 광고 생성자와 CM 간의 합의를 통해 결정됩니다. 그리고, 사용자는 주기적으로 보상을 claim하게 됩니다. 

 

Summary of cryptographic notation below - Image from [7]

 

THEMIS: A Decentralized Ad Platform

기존 StrawTHEMIS [2]에서는 중앙집중형이며 auditability가 부족하여 아래와 같은 한계점이 존재했습니다:

 

• 광고주는 각 광고 캠페인에 대한 보상 정책을 맹목적으로 신뢰할 수 밖에 없는 CM에 모두 의존하였습니다.
• 사용자와 광고주 간의 payout 정책과 정확한 보상은 모두 CM에 의존하였습니다.
• 광고주는 광고에 대한 Performance 분석을 받지 못했습니다. 더욱이, CM 또한 그러한 정보를 가지고 있지 못하였습니다.

이러한 이슈를 해결하기 위해서 THEMIS는 business와 payment 로직이 smart contract를 통해 조정되는 분산형 PoA ledger를 사용하였습니다. THEMIS의 모든 참여자는 모두 protocol을 정확하게 실행하고 있는지 검증할 수 있고, 검증력과 관련해서는 사전에 어떠한 trust도 요구하지 않습니다. 구체적으로 아래 2개의 smart contract를 정의하였습니다:

 

• The Policy Smart Contract (PSC): PSC는 사용자 보상을 지불하고 payment 요청을 검증하는 부분을 담당합니다. 더욱이, 이 smart contract에 Enc P가 저장됩니다.
• The Fund Smart Contract (FSC): FSC는 캠페인을 운영하는데 필요한 fund를 받고 escrow합니다. FSC는 1) 사용자 보상에 필요한 fund, 2) 광고주 환불, 3) CF에게 지불한 처리 비용 3가지를 지불하는 것을 담당합니다.

 

THEMIS에서는 기존 CM과 같은 central trusted authority 대신에 Campaign Facilitator(CF)를 이용합니다. CF의 책임은 1) 광고주의 정책(광고 당 보상, 광고 당 impression 등)에 대한 협의, 2) PoA에 smart contract를 배포, 3) on-chain payments  처리입니다. 모두가 다른 CFs의 행동을 audit하고 검증할 수 있기에, 광고주는 CF의 평판에 따라 원하는 CF를 골라 협업할 수 있습니다. CF는 광고주로부터 processing fees를 받기에 ad catalog를 처리하는 데 필요한  tasks들을 처리하도록 인센티브를 받습니다.

 

마지막으로 광고캠페인에 대한 performance를 광고주에게 제공하기 위해서, THEMIS는 privacy를 보호하며 ad interaction 분석을 계산하는 multiparty 프로토콜을 실행하도록 사용자를 독려합니다. 

 

A high-level overview of the user rewards claiming procedure in THEMIS - Image from [8]

 

Phase 1. 리워드 설정

먼저 광고주는 그들의 광고캠페인이 (선택한) CF에 의해 처리되는 다음번의 ad-catalog에 넣기 위해서, CD에 광고정책을 송신해야 합니다. 그 부분을 위해서는 각 광고주는 CF와 각 광고캠페인 S에 대해 하나의 symmetric key를 교환합니다. 그리고 그것은 상응하는 광고 캠페인을 encrypt하고 그것을 CF에 각 광고주의 광고 creatives와 함께 송신합니다. 

 

마지막으로, CF는 1) 정책을 decrypt하고 체크하고, 2) 다양한 광고주의 암호화된 정책을 합쳐서 암호화된 정책 vector인 Enc P로 만들고, 3) 이 ad-catalog 버젼에 대한 2개의 smart contract를 배포합니다. 게다가, 그 CF는 모든 광고주의 secret keys들도 구성된 하나의 vector S를 생성합니다:

 

Image from [7]

 

그리고, CF는 S의 각 요소를 PoA validator 노드의 public key pk로 encrypt한 하나의 vector인 Enc S를 생성합니다:

 

Image from [7]

이후, CF는 Enc S를 PSC에 저장하여 PoA validators가 decrypt하고 사용자 ad interaction vectors에 상응하는 정책을 적용할 수 있도록 합니다. 이러한 symmetric keys로 암호화하고 symmetric keys를 validators public key로 암호화하는 과정은 Hybrid Public Key Encryption으로 이루어져야 합니다.

 

PSC가 배포되고 나면, 광고주는 CF와 동의한 정책들을 Enc P가 암호화하는지 반드시 검증해야 합니다 (위 이미지의 1c). 구체적으로는:

 

1. 먼저 광고주는 PSC의 public storage로부터 Enc P vector를 fetch하고 상응하는 symmetric key S[i]를 사용해서 정책과 Enc P[i]를 복호화하고 그것이 정확한 값인지 검증하여야 합니다.
2. 두 번째로, 광고주는 FSC로부터 escrow 계정 주소를 fetch하여 escrow 계정에 funds를 송금하여야 합니다. 필요한 funds의 양은 원하는 광고 당 impression과 그것에 해당되는 policy p[i]의 일부, 그리고 CF에 지불한 처리비용에 의해 결정됩니다. 캠페인이 끝나면, 광고주는 사용자에 의한 최종 impression viewed/clicked에 따라 환불 받습니다. 캠페인 funds를 지불하면서, 광고주는 암시적으로 배포된 광고 정책을 확인합니다.

FSC가 광고주가 escrow 계정에 정확한 양의 funds를 송금한 것을 확인하면, 캠페인은 시작되고 확정됩니다.

 

Phase 2. 광고 리워드 청구(Claiming)

광고 리워드를 청구하기 위해서는, 각 사용자는 ephemeral한 key pair(pk, sk)를 생성하고 컨센서스 풀에 의해 생성된 public threshold key pk[T]를 얻습니다. 이 2가지 키를 사용해서 각 사용자는 그들의 광고 interaction vector를 복호화하여 2개의 ciphertexts를 생성합니다: 1) 광고 리워드 청구에 사용되는 EncVec, 2) 광고주 리포팅에 사용되는 EncVec'.

 

기존의 중앙형 StrawTHEMIS와 달리, THEMIS에서는 집계 연산이 PSC(위 이미지의 2b)를 통해 실행됩니다. 그러므로, 그 사용자는 PSC의 public endpoint를 call하고 2가지 ciphertexts를 보냅니다. 그 사용자가 청구할 수 있는 암호화된 리워드 합계를 계산하기 위해서 (위 이미지 2b), PoA validator는 PSC를 아래와 같이 실행합니다:

 

1. Validator는 각 정책 P[i]를 Enc S(여기서 THMEIS는 private input transaction을 사용함)를 사용해 복호화합니다.
2. 그것은 기반한 암호화 구조의 additively homomorphic property인 EncVec ciphertext에 적용됩니다.
3. 그리고 그 결과(Aggr.Res)를 smart contract public store에 저장합니다.

Phase 3. Payment  요청

PSC가 집계된 결과를 계산하고 나면, 사용자는 payment 요청을 생성하는데, 그것이 유효하다면 FSC에 publish됩니다. 좀 더 기술적으로 보자면, 그 사용자는 1) 주소 Addr와 같이 ephemeral 블록체인 계정(한 번의 요청에만 사용)을 생성하고. 2) Aggr.Res는 fetch하고 복호화하여 복호화된 Dec.Aggr.Res를 얻고, 정확한 복호화였다는 증명을 생성합니다. 이러한 방식으로 그 사용자는 3) 아래 3가지로 구성된 튜플 형태의 payment 요청을 생성합니다:

 

Image from [7]

이후 (iv) 그 사용자는 PSC의 public endpoint에 input으로 validators keys로 암호화된 ε, Enc(pk[v], ε) 넣고 호출합니다. 해당 함수는 이후 해당 사용자의 리워드 합계 Aggr.Res를 fetch하고, 요청을 복호화하고, zero knowledge proof를 입증합니다. 만약 해당 proof가 유효하다면, Addr과 해당 주소로 지불될 양과 같이 FSC에 저장합니다. 이러한 방식으로, FSC는 paid로 마크되기 전까지 사용자 payment를 쌓아둡니다. 

 

Phase 4. Payment 확정

해당 프로토콜의 마지막 단계는 사용자 payment와 광고주 환불을 확정하는 것입니다.

 

구체적으로 THEMIS에서 해당 사용자 리워드 확정은 총 지급 리워드에 대한 privacy를 보호하기 위해서 confidentail한 방법을 통해 진행되어야 합니다. 이것을 이루기 위해서, CF는 FSC로부터 pending인 payment 요청을 fetch하고 payments 지불을 진행하기 위해 필요한 총 액수를 계산합니다. 

 

다음 단계로 (4a), 그 CF는 payments를 처리하기 위해서 필요한 tokens을 송신해줄 것을 FSC에 요청하는 public 함수를 호출합니다. 만약 CF가 이상한 행동(부정확한 양의 토큰 요청 등)을 보인다면, 감지되고 광고주나 사용자가 그 이상행동을 입증할 수 있습니다.

 

마지막으로, CF는 confidentail한 payment 방식을 통해 각 리워드 payment를 처리할 수 있습니다. Payments를 정확하게 마무리한 후(그리고 광고주나 사용자로부터 이상 알림이 없으면), 해당 CF는 FSC로부터 처리 비용을 받습니다.

 

사용되지 않은 funds가 있을 경우에 광고주는 환불을 받아야 합니다. 그 부분을 위해서 FSC는 광고주 리포팅 시 컨센서스 풀이 계산한 aggregate clicks 당 광고 vector를 사용합니다. 이 vector와 합의된 리워드에 기반해서 FSC는 사용되지 않은 funds를 돌려줍니다.

 

 

IPFS 지원

최근 Brave는 분산 파일 시스템이며 네트워크 프로토콜인 IPFS 지원을 시작하였습니다 [14].

 

 

Reference

[1] brave.com/category/security-privacy-category/

[2] brave.com/themis/

[3] brave.com/intro-to-brave-ads/

[4] Blocking goals and policy

[5] www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

[6] brave.com/privacy-updates-4/

[7] arxiv.org/abs/2007.05556

[8] brave.com/themis-smart-contracts-and-sidechains/

[9] link.springer.com/article/10.1007/s00145-006-0347-3

[10] Basic Attention Token (BAT) Blockchain Based Digital Advertising

[11] Serving Ads from localhost for Performance, Privacy, and Profit

[12] Adnostic: Privacy-Preserving Targeted Advertising

[13] Cameo: A middleware for mobile advertisement delivery

[14] brave.com/ipfs-support/