0. Wprowadzenie
Web3 przekształcił wartość danych, jednak rozproszona struktura blockchainu jest zamkniętym systemem deterministycznym, a inteligentne kontrakty nie realizują funkcji zewnętrznych wywołań API, w efekcie narodził się mechanizm Oracle, który ma pomóc inteligentnym kontraktom w pozyskiwaniu danych zewnętrznych .
Przesyłanie danych spoza łańcucha do łańcucha nie jest trudne. Trudne jest zaprojektowanie i wytworzenie zaufania za pomocą technologii i mechanizmów. Problem wyroczni wymaga rozwiązania problemu zaufania od źródła danych, przez przetwarzanie, aż do zasilania cenowego.
Podstawowym warunkiem uzyskania statusu wyroczni uznanej publicznie jest decentralizacja, czyli dopuszczenie pojedynczych punktów awarii i weryfikacji danych. Powszechnym rozwiązaniem decentralizacji łańcucha jest wykorzystanie wielu węzłów danych w celu utworzenia zdecentralizowanej sieci Oracle. Każdy węzeł będzie zbierał dane i wprowadzał je do inteligentnego kontraktu w łańcuchu bloków po osiągnięciu konsensusu.
Architektura ogniwa łańcucha
Obecnym głównym zastosowaniem wyroczni jest dostarczanie źródła cen dla DeFi i bezpieczna, terminowa i dokładna aktualizacja cen aktywów bazowych. Według danych DefiLlama, Chainlink jest jednym z największych rozwiązań Oracle na rynku, o łącznej gwarantowanej wartości około 11 miliardów dolarów w momencie pisania tego tekstu, co stanowi 46% całego rynku.
Dane rynkowe Oracle
Wraz z rozwojem technologii blockchain zapotrzebowanie na dane poza łańcuchem staje się coraz większe. Same ceny DeFi nie są już w stanie zaspokoić potrzeb programistów. Zdecydowana większość danych w świecie rzeczywistym i Web2 nie jest publicznie dostępna, konieczne jest jednak zbudowanie innowacyjnych scenariuszy aplikacji Web3 (pożyczki kredytowe, sieci społecznościowe, DID, KYC/AML itp.). Nowa generacja wyroczni musi zatem umożliwić inteligentnym kontraktom obsługę złożonych przypadków użycia obejmujących dane wrażliwe w sposób chroniący prywatność.
DECO to rozwiązanie Chainlink w tym kierunku, wykorzystujące technologię dowodu zerowej wiedzy, aby umożliwić użytkownikom generowanie prywatnych dowodów danych poza łańcuchem dla inteligentnych kontraktów bez ujawniania danych opinii publicznej lub samemu węzłowi Oracle. DECO można podłączyć do istniejących API i nie wymaga żadnych modyfikacji ze strony dostawcy danych API, nawet jeśli wymagane jest uwierzytelnienie użytkownika końcowego (np. uzyskanie salda konta bankowego wymaga zalogowania). Obecnie osiągnął fazę alfa i testuje weryfikację koncepcji z wieloma partnerami.
1. Tło
Znajdują się tutaj niezbędne informacje na temat TLS i ZKP, a DECO jest zbudowane w oparciu o te protokoły.
1.1 TLS
TLS (Transport Layer Security) to potężny, szeroko stosowany protokół bezpieczeństwa, dawniej SSL, zaprojektowany w celu promowania prywatności i bezpieczeństwa danych w komunikacji internetowej, zlokalizowany w warstwie protokołów aplikacji i warstwie TCP/IP. Głównym przypadkiem użycia jest szyfrować komunikację pomiędzy aplikacjami internetowymi i serwerami.
Komunikacja za pośrednictwem protokołu HTTP odbywa się w postaci zwykłego tekstu i jest podatna na podsłuchiwanie, manipulację i podszywanie się. Dzięki TLS dane HTTP, które użytkownicy wysyłają do witryny internetowej (kliknięcie, wypełnienie formularza itp.) oraz dane HTTP wysyłane przez witrynę do użytkownika, są szyfrowane, a odbiorca musi użyć klucza, aby odszyfrować zaszyfrowane dane. HTTPS implementuje szyfrowanie TLS w oparciu o protokół HTTP i jest standardową praktyką w przypadku witryn internetowych. Strony internetowe muszą zainstalować certyfikat TLS na swoim serwerze źródłowym, a przeglądarki oznaczą wszystkie witryny inne niż HTTPS jako niebezpieczne.
Witryna internetowa bez protokołu HTTPS
Podstawową ideą TLS jest wykorzystanie szyfrowania kluczem publicznym. Certyfikat TLS/SSL udostępniany publicznie przez witrynę zawiera klucz publiczny, a klucz prywatny jest zainstalowany na serwerze źródłowym i jest własnością witryny. Klient najpierw prosi serwer o klucz publiczny certyfikatu cyfrowego, a następnie używa klucza publicznego do zaszyfrowania informacji. Po odebraniu przez serwer tekstu zaszyfrowanego używa własnego klucza prywatnego do jego odszyfrowania.
Występuje tu problem. Szyfrowanie klucza publicznego wymaga zbyt wielu obliczeń. Aby skrócić czas sesji, klient i serwer generują „klucz sesji” dla każdej sesji i używają go do szyfrowania informacji. Ponieważ „klucz sesji” jest szyfrowany symetrycznie, szybkość operacji jest bardzo duża, a klucz publiczny serwera służy jedynie do szyfrowania samego „klucza sesji”, co skraca czas operacji szyfrowania.
Dlatego protokół TLS można głównie podzielić na dwie warstwy:
Protokół uzgadniania do negocjacji klucza uwierzytelniającego: komunikacja w postaci zwykłego tekstu, wzajemne potwierdzanie poprzez szyfrowanie asymetryczne, wzajemna weryfikacja, ustalanie zastosowanego algorytmu szyfrowania i generowanie spójnego klucza sesyjnego do rejestrowania symetrycznego szyfrowania umowy
Protokół nagrywania dla transmisji szyfrowanej symetrycznie: główna część protokołu, która chroni poufność i integralność transmisji danych
Stos protokołów TLS
Zestaw szyfrów TLS (CipherSuite) to kombinacja 4 algorytmów:
Uwierzytelnianie: Określ autentyczność tożsamości, do głównych należą RSA/DSA/ECDSA
Wymiana kluczy: komunikujące się strony negocjują klucz używany do szyfrowania. Głównym kluczem jest ECDHE.
Szyfrowanie: Szyfrowanie symetryczne w komunikacji, trendem jest stosowanie GCM
MAC (kod uwierzytelnienia wiadomości, kod uwierzytelnienia wiadomości): używany do weryfikacji integralności danych i tego, czy dane nie zostały naruszone. Do głównych należą SHA256/SHA384/SHA1 itp.
TLS ma ogromne możliwości, ale ma swoje ograniczenia: nie pozwala użytkownikowi udowodnić osobie trzeciej, że dane, do których uzyskuje dostęp, faktycznie pochodzą z określonej witryny internetowej. Ponieważ transmisja danych wykorzystuje szyfrowanie symetryczne, użytkownik i serwer mają do tego prawo taką samą możliwość podpisywania danych. Intuicyjnym przykładem jest to, że informacje o tożsamości Alicji są przechowywane na serwerach wielu stron internetowych. Można łatwo sprawdzić, czy Alicja ma ukończone 18 lat, ale Alicji trudno jest to udowodnić Bobowi. Alicja mogłaby zrobić zrzut ekranu ze strony internetowej, ale zrzuty ekranu można łatwo sfałszować i nawet gdyby okazało się, że zrzut ekranu jest autentyczny, ujawniłby informacje – dokładną datę urodzenia Alicji, a nie tylko fakt, że ma ukończone 18 lat.
Maszyna Oracle musi być zdecentralizowana (nie opierać się na jednym punkcie, takim jak serwer strony internetowej), aby udowodnić pochodzenie prywatnych danych spoza łańcucha i być wykorzystywana przez inteligentne kontrakty bez utraty prywatności. Dowody z wiedzą zerową mogą pomóc w osiągnięciu tych funkcji.
1,2 CPC
Zero Knowledge Proof (ZKP) zyskał szerokie zainteresowanie w blockchainie, a jego głównymi zastosowaniami są ZK-Rollup (w projekcie algorytmu poczyniono wiele kompromisów w celu poprawy efektywności ekspansji, bez Validity Proof ZK) i technologia prywatności (prawdziwe zk). Dowód z wiedzą zerową pozwala Proverowi udowodnić Weryfikatorowi, że ma rozwiązanie (Świadek), które może rozwiązać określony problem obliczeniowy (Stwierdzenie) bez ujawniania żadnych dodatkowych informacji o rozwiązaniu (Świadek).
Typowy system ZK można podzielić na front-end i back-end.
Front-end: Kompilator, który zapisuje instrukcję wymagającą weryfikacji w języku specyficznym dla domeny (DSL), a następnie kompiluje ją do formatu przyjaznego ZK, takiego jak obwody arytmetyczne;
Backend: system dowodowy, interaktywny system demonstracyjny sprawdzający poprawność obwodu, np. Marlin, Plonky2, Halo2;
układu ZK
Proces konstruowania interaktywnych pytań w systemie otwartym, takim jak blockchain, jest bardzo skomplikowany, a dowód musi zostać zweryfikowany przez kogokolwiek w dowolnym momencie. Dlatego system ZK w aplikacji blockchain jest zwykle nieinteraktywny, a Fiat-Shamir- można zastosować interaktywną konwersję heurystyczną na nieinteraktywną.
2. Jak działa DECO
DECO zostało rozbudowane w oparciu o protokół HTTPS/TLS, dzięki czemu z serwera można korzystać bez modyfikacji.
Podstawową ideą DECO jest zbudowanie nowatorskiego, trójstronnego protokołu uzgadniania pomiędzy Proverem (użytkownikiem lub Dappem z uruchomionym DECO Prover), Verifierem (Chainlink Oracle z uruchomionym DECO Verifier) i Serwerem (dostawcą danych).
Pochodzenie: Kiedy Prover wysyła zapytanie o informacje do serwera WWW, Verifier jest świadkiem procesu interakcji i otrzymuje zobowiązanie utworzone przez Prover na podstawie danych sesji TLS, dzięki czemu Verifier może zweryfikować prawdziwe źródło informacji;
Prywatność: jeśli dane nie wymagają prywatności, Prover może bezpośrednio dostarczyć klucz, który może odszyfrować dane do Verifier, aby programiści mogli dodać dane do Dapp, jeśli wymagana jest prywatność, Prover używa ZKP do wygenerowania dowodu, który nie powoduje wycieku danych dla programistów dodaj do Dappa.
Przykład DECO
W szczególności protokół DECO składa się z trzech faz:
Uzgadnianie trójstronne, Prover, Verifier i Server ustanawiają klucz sesji w specjalnym formacie, aby zapewnić, że dane nie zostaną sfałszowane;
Wykonanie zapytania, Prover używa Query ze swoimi prywatnymi parametrami θs (takimi jak hasło do konta, klucz API) do wysyłania zapytań o dane z Serwera;
Generowanie dowodu, Prover udowadnia, że odpowiedź spełnia wymagane warunki.
Architektura DECO
2.1 Trójstronny uścisk dłoni
Uwaga: Poniższe instrukcje opierają się na algorytmie szyfrowania AES-CBC-HMAC. TLS 1.3 wykorzystuje jedynie bezpieczniejszy AEAD jako algorytm szyfrowania, używając jednego klucza do szyfrowania i MAC, i nie jest wymagany żaden klucz MAC. Jednakże, ze względu na kluczową niezależność protokołu TLS 1.3, można również skonstruować trójstronny protokół uzgadniania o podobnej złożoności.
Prover P nie może zaciągnąć zobowiązania po uzyskaniu klucza MAC, w przeciwnym razie może sfałszować lub manipulować danymi. Dlatego też ideą uzgadniania trójstronnego jest użycie Prover P i Verifier V razem jako klientów TLS w celu ustanowienia wspólnego połączenia. Klucz MAC z serwerem TLS S . Klucz MAC k jest dzielony po stronie klienta, Prover przechowuje kp, a Verifier przechowuje kv, k=kp+kv. Jednocześnie P posiada także klucz szyfrujący k^{Enc} używany w algorytmie szyfrowania symetrycznego. Jeśli weryfikator nie czyni zła, trójstronny protokół uzgadniania może zapewnić, że danych nie będzie można podrobić.
2.2 Wykonanie zapytania
Po uzgodnieniu, ponieważ klucz MAC jest współdzielony w tajemnicy, P i V wykonują protokół interaktywny (bezpieczne obliczenia dwustronne) i wykorzystują parametry prywatne θs do skonstruowania zaszyfrowanego zapytania TLS Query Q. Następnie P wysyła Q do S jako standardowy klient TLS. W tym procesie tylko P komunikuje się z S i żadne wysłane przez niego zapytanie nie może zostać ujawnione do V.
Po otrzymaniu odpowiedzi R od S, P przyłącza się do sesji, wysyłając zaszyfrowany tekst Rˆ do V i odbiera kv V w celu sprawdzenia autentyczności odpowiedzi R.
2.3 Generowanie dowodu
Następnie P musi udowodnić, że tekst jawny R odpowiadający zaszyfrowanemu tekstowi Rˆ spełnia pewne atrybuty. Jeśli prywatność nie jest wymagana, klucz szyfrujący k^{Enc} może zostać bezpośrednio ujawniony. Jeśli wymagana jest prywatność, musi to być dowód z wiedzą zerową używany.
Jeśli tekst jawny składa się z kilku bloków danych R=(B1,...,Bn), DECO wykorzystuje otwieranie selektywne w celu wygenerowania dowodu o wiedzy zerowej:
Ujawnij tylko określone wiersze danych: Udowodnij, że i-ty blok danych R to Bi, nie ujawniając innych bloków danych
Ukryj wiersze danych zawierające dane prywatne: udowodnij, że R_{-i} i R są równe, z wyjątkiem tego, że Bi zostało usunięte
Jednak wielokrotnie weryfikator musi zweryfikować, czy ujawniony podciąg pojawia się we właściwym kontekście, a powyższe metody nie wystarczą, aby zapewnić ochronę integralności kontekstu. Aby to zrekompensować, DECO wykorzystuje technologię zwaną dwuetapowym analizowaniem z wiedzą zerową: Prover analizuje dane sesji lokalnie, określa najmniejszy podciąg, który może przekonać weryfikatora, a następnie wysyła dane do weryfikatora. W ten sposób zostaje osiągnięta prywatność.
Zgrabne, nieinteraktywne (NIZK) dowody o wiedzy zerowej zwykle wiążą się z dużym obciążeniem po stronie Provera w zakresie obliczeń i pamięci. Ponieważ określono weryfikator ZKP wykonywany przez DECO (wyrocznia Chainlink), można zastosować bardziej wydajne interaktywne dowody o wiedzy zerowej, takie jak mniejsze zużycie pamięci, unikanie zaufanych ustawień, tanie obliczenia itp.
W bieżącym teście alfa firma DECO nadal używa Dapp do działania jako Prover. W przyszłych iteracjach planuje się, że Prover będzie mógł być wdrażany lokalnie przez użytkowników końcowych (takich jak telefony komórkowe) lub w zaufanym środowisku wykonawczym (TEE).
3. Zastosowanie
DECO może zweryfikować ważność informacji o tożsamości użytkowników poza łańcuchem, zapewniając jednocześnie prywatność danych, odblokowując w ten sposób wiele innowacyjnych scenariuszy aplikacji Web3, od ekonomicznych po społeczne.
Samodzielne odzyskiwanie pomocy społecznej/dowód tożsamości prawnej (kim jesteś): Korzystając z DECO, wykorzystaj strony internetowe instytucji (banki, media społecznościowe), które mają już dojrzałe mechanizmy uwierzytelniania, aby działać jako jeden ze strażników naprawy społecznej.
Udzielanie kredytów/dowód środków (ile masz pieniędzy): Teller to protokół pożyczek kredytowych DeFi, który wykorzystuje protokół DECO w celu udowodnienia, że saldo aktywów użytkownika na rachunku bankowym poza łańcuchem przekracza dynamiczny minimalny próg wymagany dla pożyczek.
Follower Proof/Interaction Proof (z kim miałeś interakcję): Clique to wyrocznia społecznościowa opracowująca rozwiązanie, które zapewnia wpływ użytkowników poza łańcuchem, lojalność na różnych platformach mediów społecznościowych (np. przy użyciu API Twittera) i dogłębną analizę wpisów.
Tożsamość cyfrowa/dowód tożsamości społecznościowej (masz konto online): PhotoChromic to rozwiązanie w zakresie tożsamości cyfrowej, które wykorzystuje DECO do łączenia użytkowników Web3 z ich kontami społecznościowymi na Twitterze lub Discordzie bez ujawniania przy tym podstawowych danych osobowych. Aplikacje mogą odfiltrowywać dane rzeczywiste użytkownicy.
Odporność DAO na ataki Sybil, SBT, KYC/AML itp.
4. Inni gracze
Axiom buduje wyrocznię ZK dla Uniswap TWAP, wykorzystując w całości weryfikowalne źródła danych z łańcucha, bardziej podobne do indeksowania (np. Hyper Oracle); i DECO są bardziej komplementarne niż konkurencyjne: coraz więcej działań gospodarczych będzie się działo w łańcuchu, wyłącznie w nim Wyrocznie łańcuchowe to jeden kierunek; coraz więcej danych spoza łańcucha należy przesyłać do łańcucha, a wyrocznie dotyczące prywatności poza łańcuchem również są kierunkiem.
Empiric Network wykorzystuje technologię ZK do umieszczenia całej Oracle w łańcuchu. Nie ma infrastruktury poza łańcuchem, przez którą muszą przepływać dane. To nie jest ten sam kierunek, co DECO.
4. Wniosek
Chainlink jest absolutnym liderem na rynku obecnych wyroczni. Dzięki wyroczni DECO ogromne prywatne dane poza łańcuchem będą wywoływane przez inteligentne kontrakty w ramach łańcucha zgodnie z założeniem ochrony prywatności, co może odblokować wiele scenariuszy zastosowań, od finansów po tożsamość i sieci społecznościowe. Potencjalne ryzyko to szybkość generowania dowodu przez Prover i problemy z centralizacją Verifier.