0. Úvod

Web3 přetvořil hodnotu dat, ale distribuovaná struktura blockchainu je uzavřený deterministický systém a chytré kontrakty neimplementují funkci externích volání API. Výsledkem je, že se zrodil mechanismus oracle, který pomáhá chytrým kontraktům získávat externí data .

Není obtížné nahrát data mimo řetězec do řetězce Co je obtížné, je navrhnout a vytvořit důvěru prostřednictvím technologie a mechanismů.

Základní podmínkou pro to stát se veřejně uznávaným orákulem je decentralizace, tedy zda jsou povoleny jednotlivé body selhání a ověřování dat. Běžným řešením decentralizace řetězce je použití více datových uzlů k vytvoření decentralizované sítě Oracle. Každý uzel bude po dosažení konsensu shromažďovat data a vkládat je do chytré smlouvy na blockchainu.

 

Architektura Chainlink

Současné hlavní využití oracles je poskytovat Price Feed pro DeFi a aktualizovat cenu podkladových aktiv bezpečně, včas a přesně. Podle údajů DefiLlama je Chainlink jedním z největších řešení Oracle na trhu s celkovou garantovanou hodnotou přibližně 11 miliard USD v době psaní tohoto článku, což představuje 46 % z celkového trhu.

 

Údaje o trhu Oracle

S rozvojem blockchainu je poptávka po off-chain datech stále silnější a silnější. Naprostá většina dat v reálném světě a Web2 není veřejně přístupná, ale je nutné vybudovat inovativní scénáře Web3 aplikací (úvěrové půjčky, sociální sítě, DID, KYC/AML atd.). Nová generace věštců proto potřebuje umožnit inteligentní smlouvy pro podporu komplexních případů použití zahrnujících citlivá data způsobem, který chrání soukromí.

DECO je řešení Chainlink v tomto směru, které využívá technologii nulových znalostí, která uživatelům umožňuje generovat off-chain důkazy soukromých dat pro inteligentní smlouvy, aniž by byla data odhalena veřejnosti nebo samotnému věšteckému uzlu. DECO lze zapojit do stávajících API a nevyžaduje žádné úpravy ze strany poskytovatele dat API, i když je vyžadována autentizace koncového uživatele (například získání zůstatku na bankovním účtu vyžaduje přihlášení). Nyní dosáhla fáze alfa a testuje proof-of-concept s více partnery.

1. Pozadí

Zde je poskytnuto nezbytné zázemí pro TLS a ZKP a DECO je postaveno na těchto protokolech.

1.1 TLS

TLS (Transport Layer Security) je výkonný, široce nasazovaný bezpečnostní protokol, dříve SSL, navržený k podpoře soukromí a zabezpečení dat internetové komunikace, který se nachází na vrstvě aplikačního protokolu a vrstvě TCP/IP Mezi nimi je hlavním případem použití šifrovat komunikaci mezi webovými aplikacemi a servery.

Komunikace přes HTTP probíhá v prostém textu a je náchylná k odposlouchávání, manipulaci a předstírání jiné identity. U TLS jsou HTTP data, která uživatelé odesílají na webovou stránku (kliknutí, vyplnění formuláře atd.), a HTTP data, která web odešle uživateli, šifrována a příjemce musí k dešifrování zašifrovaných dat použít klíč. HTTPS implementuje šifrování TLS založené na protokolu HTTP. Jedná se o standardní postup pro weby, které potřebují nainstalovat certifikát TLS na svůj zdrojový server a prohlížeče označí všechny weby, které nejsou zabezpečené protokolem HTTPS.

 

Web bez HTTPS

Základní myšlenkou TLS je použití šifrování veřejným klíčem. Certifikát TLS/SSL veřejně sdílený webem obsahuje veřejný klíč a soukromý klíč je nainstalován na zdrojovém serveru a je vlastněn webem. Klient nejprve požádá server o veřejný klíč digitálního certifikátu a poté použije veřejný klíč k zašifrování informací poté, co server obdrží šifrovaný text, použije k jeho dešifrování svůj vlastní soukromý klíč.

Zde je problém. Šifrování veřejného klíče vyžaduje příliš mnoho výpočtů. Aby se zkrátil čas strávený relací, generují klient a server pro každou relaci „klíč relace“ a používají jej k šifrování informací. Vzhledem k tomu, že „klíč relace“ je symetricky šifrován, rychlost operace je velmi vysoká a veřejný klíč serveru se používá pouze k šifrování samotného „klíče relace“, což zkracuje dobu spotřebovanou operací šifrování.

Proto lze protokol TLS rozdělit především do dvou vrstev:

  1. Protokol Handshake pro vyjednávání ověřovacího klíče: komunikace ve formátu prostého textu, vzájemné potvrzení prostřednictvím asymetrického šifrování, vzájemné ověřování, stanovení šifrovacího algoritmu, který se má použít, a generování konzistentního klíče relace pro záznam symetrického šifrování dohody

  2. Záznamový protokol pro symetricky šifrovaný přenos: hlavní část protokolu, která chrání důvěrnost a integritu přenosu dat

 

Zásobník protokolů TLS

Šifrovací sada TLS (CipherSuite) je kombinací 4 algoritmů:

  1. Autentizace: Určete pravost identity, hlavní proudy jsou RSA/DSA/ECDSA

  2. Výměna klíčů: Komunikující strany si vyjednají klíč používaný pro šifrování.

  3. Šifrování: Symetrické šifrování pro komunikaci, trendem je použití GCM

  4. MAC (Message Authentication Code, Message Authentication Code): používá se k ověření integrity dat a toho, zda s daty nebylo manipulováno. Mezi běžné patří SHA256/SHA384/SHA1 atd.

TLS je velmi výkonný, ale má omezení: neumožňuje uživateli prokázat třetí straně, že data, ke kterým přistupuje, skutečně pocházejí z konkrétní webové stránky. Protože přenos dat používá symetrické šifrování, uživatel i server to mají stejnou schopnost podepisovat data. Intuitivním příkladem je, že informace o Alicině identitě jsou uloženy na serverech mnoha webových stránek. Lze snadno ověřit, že Alici je více než 18 let, ale pro Alici je obtížné to Bobovi dokázat. Alice by mohla pořídit snímek obrazovky z webové stránky, ale snímky obrazovky jsou snadno falešné, a i kdyby bylo možné prokázat, že snímek obrazovky je autentický, odhalil by informace - přesné datum narození Alice, nejen skutečnost, že je starší 18 let.

Stroj Oracle musí být decentralizovaný (nespoléhat se na jediný bod, jako je webový server), aby prokázal původ soukromých dat mimo řetězec a být používán inteligentními smlouvami, aniž by došlo k úniku soukromí. Důkazy nulových znalostí mohou pomoci dosáhnout těchto funkcí.

1.2 CPC

Zero Knowledge Proof (ZKP) získal širokou pozornost v blockchainu a jeho hlavními aplikacemi jsou ZK-Rollup (v návrhu algoritmu bylo učiněno mnoho kompromisů s cílem zlepšit efektivitu expanze, bez ZK Validity Proof) a technologie ochrany soukromí. (skutečné zk). Důkaz nulových znalostí umožňuje společnosti Prover dokázat Verifieru, že má řešení (Witness), které může vyřešit určitý výpočetní problém (Statement), aniž by prozradil jakékoli další informace o řešení (Witness).

Typický systém ZK lze rozdělit na front-end a back-end.

  1. Front-end: Kompilátor, který zapíše prohlášení, které je třeba ověřit, do jazyka specifického pro doménu (DSL) a poté jej zkompiluje do formátu vhodného pro ZK, jako jsou aritmetické obvody;

  2. Backend: proof system, interaktivní demonstrační systém, který kontroluje správnost obvodu, jako Marlin, Plonky2, Halo2;

 

systém ZK

Proces vytváření interaktivních otázek na otevřeném systému, jako je blockchain, je velmi komplikovaný. Důkaz musí být kdykoli ověřen kýmkoli, a proto je systém Fiat-Shamir obvykle neinteraktivní používá se pro interaktivní heuristický převod na neinteraktivní.

2. Jak DECO funguje

DECO bylo rozšířeno na základě protokolu HTTPS/TLS tak, aby bylo možné server používat bez úprav.

Základní myšlenkou DECO je vybudovat nový protokol pro handshake tří stran mezi Proverem (uživatel nebo Dapp s DECO Prover), Verifier (Chainlink oracle s DECO Verifier) ​​a Serverem (poskytovatel dat).

  • Původ: Když se Prover dotazuje na informace z webového serveru, Verifier je svědkem procesu interakce a obdrží závazek vytvořený Proverem na data relace TLS, takže Verifier může ověřit skutečný zdroj informací;

  • Ochrana osobních údajů: Pokud data nevyžadují soukromí, může Prover přímo poskytnout klíč, který může data dešifrovat do Verifieru, aby vývojáři mohli přidat data do Dapp, pokud je vyžadováno soukromí, Prover používá ZKP ke generování důkazu, který vývojářům neuniká přidat do Dapp.

 

Příklad DECO

Konkrétně se protokol DECO skládá ze tří fází:

  1. Handshake tří stran, Prover, Verifier a Server vytvoří klíč relace ve speciálním formátu, aby bylo zajištěno, že data nemohou být padělána;

  2. Provádění dotazu, Prover používá dotaz se svými soukromými parametry θs (jako je heslo účtu, klíč API) k dotazování na data ze serveru;

  3. Generování důkazu, Prover dokazuje, že odpověď splňuje požadované podmínky.

 

Architektura DECO

2.1 Potřesení rukou tří stran

Poznámka: Následující pokyny jsou založeny na šifrovacím algoritmu AES-CBC-HMAC TLS 1.3 zachovává pouze bezpečnější AEAD jako šifrovací algoritmus s použitím jednoho klíče pro šifrování a MAC a není vyžadován žádný klíč MAC. Vzhledem ke klíčové nezávislosti TLS 1.3 však lze sestavit i protokol třístranného handshake s podobnou složitostí.

Prover P se po získání MAC klíče nemůže zavázat, jinak může data zfalšovat nebo s nimi manipulovat. Proto je myšlenkou třístranného handshake použít Prover P a Verifier V jako klienty TLS k vytvoření sdílené MAC. klíč se serverem TLS S . MAC klíč k je rozdělen na straně klienta, Prover má kp a Verifier má kv, k=kp+kv. Současně P také obsahuje šifrovací klíč k^{Enc} používaný pro symetrický šifrovací algoritmus. Pokud Verifier nedělá zlo, protokol třístranného handshake může zajistit, že data nebudou padělatelná.

2.2 Provedení dotazu

Po handshake, protože MAC klíč je tajně sdílen, P a V provedou interaktivní protokol (zabezpečený výpočet pro dvě strany) a použijí soukromé parametry θs k vytvoření šifrované dotazovací TLS zprávy Query Q. Poté se P chová jako standardní klient TLS a odešle Q do S. V tomto procesu komunikuje pouze P s S a žádný dotaz, který odešle, nemůže uniknout do V.

Po obdržení odpovědi R od S se P zapojí do relace odesláním šifrového textu Rˆ do V a přijme V's kv k ověření pravosti odpovědi R.

2.3 Generování důkazů

Dále P potřebuje dokázat, že prostý text R odpovídající šifrovému textu Rˆ splňuje určité atributy. Není-li vyžadováno soukromí, může být šifrovací klíč k^{Enc} přímo odhalen použitý.

Pokud se prostý text skládá z několika datových bloků R=(B1,...,Bn), DECO použije selektivní otevírání ke generování důkazu s nulovými znalostmi:

  • Odhalte pouze konkrétní datové řádky: Dokažte, že i-tý datový blok R je Bi, aniž byste odhalili další datové bloky

  • Skrýt datové řádky obsahující soukromá data: dokažte, že R_{-i} a R jsou si rovny, kromě toho, že Bi je smazán

 

Verifier však mnohokrát potřebuje ověřit, zda se odhalený podřetězec objevuje ve správném kontextu, a výše uvedené metody nestačí k zajištění ochrany integrity kontextu. Aby to bylo kompenzováno, DECO využívá technologii zvanou dvoustupňová analýza s nulovými znalostmi: Prover analyzuje data své relace lokálně, určí nejmenší podřetězec, který může přesvědčit Verifier, a poté data odešle do Verifieru. Tím je dosaženo soukromí.

Úhledné neinteraktivní (NIZK) důkazy s nulovými znalostmi mají obvykle vysokou režii na straně Prover, pokud jde o výpočet a paměť. Protože je specifikován Verifier of ZKP prováděný DECO (Chainlink’s oracle), lze použít efektivnější interaktivní důkazy s nulovými znalostmi, jako je menší využití paměti, vyhýbání se důvěryhodným nastavením, levné výpočty atd.

V aktuálním Alpha Testu DECO stále používá Dapp jako Prover. V budoucích iteracích se plánuje, že Prover bude možné nasadit lokálně koncovými uživateli (jako jsou mobilní telefony) nebo nasadit v Trusted Execution Environment (TEE).

3. Aplikace

DECO může ověřit platnost informací o identitě uživatelů mimo řetězec a zároveň zajistit soukromí dat, čímž odemkne mnoho inovativních scénářů Web3 aplikací, od ekonomických po sociální.

  • Samoobslužná sociální obnova / důkaz právní identity (kdo jste): Pomocí DECO využijte institucionální webové stránky (banky, sociální média), které již mají vyzrálé mechanismy ověřování, aby fungovaly jako jeden ze strážců sociální obnovy.

 

  • Úvěrové půjčování/doklad o fondu (kolik peněz máte): Teller je úvěrový protokol DeFi, který používá protokol DECO k prokázání, že zůstatek aktiv uživatele na mimořetězovém bankovním účtu překračuje dynamický minimální práh požadovaný pro půjčky.

 

  • Doklad o sledování/dokladu interakce (s kým jste komunikovali): Clique je sociální orákulum vyvíjející řešení, které poskytuje mimořetězový vliv uživatelů, loajalitu napříč různými platformami sociálních médií (např. pomocí Twitter API) a hloubkovou analýzu příspěvků.

  • Digital Identity/Social Identity Proof (máte online účet): PhotoChromic je řešení pro digitální identitu, které využívá DECO k propojení uživatelů Web3 s jejich sociálními účty na Twitteru nebo Discordu, aniž by v procesu odhalila základní osobní identifikovatelná data uživatelů.

  • Odolnost DAO vůči útokům Sybil, SBT, KYC/AML atd.

4. Ostatní hráči

  • Axiom staví ZK oracles pro Uniswap TWAP s využitím ověřitelných datových zdrojů kompletně z řetězce, podobnějších indexování (např. Hyper Oracle a DECO se více doplňují než konkurují: v řetězci se bude dít stále více a více ekonomických aktivit, čistě na-); řetězová věštci jsou jedním směrem, do řetězce je třeba nahrávat stále více a více off-chain dat a off-chain věštění soukromí jsou také směr.

  • Empiric Network používá zk computing k umístění celého věštce do řetězce Neexistuje žádná mimořetězová infrastruktura, kterou by data musela proudit. Není ve stejném směru jako DECO.

4. Závěr

Chainlink je absolutním lídrem v současných oraclech Prostřednictvím DECO oracle budou masivní off-chain soukromá data volána on-chain smart kontrakty za předpokladu ochrany soukromí, což může odemknout mnoho aplikačních scénářů od financí přes identitu až po sociální sítě. Potenciálními riziky jsou rychlost generování důkazů Prover a problémy s centralizací Verifieru.