Główna linia rozwoju kryptowalut jest niezwykle jasna. Bitcoin stworzył kryptowalutę, Ethereum stworzyło sieci publiczne, TEDA stworzyła stablecoiny, a BitMEX stworzył kontrakty wieczyste. Te cztery kreacje są jak kryptograficzne prymitywy budujące rynek wart bilion dolarów. Istnieje niezliczona ilość mitów na temat bogacenia się lub zdecentralizowane marzenia, o których ludzie zawsze pamiętają.
Trajektoria rozwoju technologii szyfrowania nie jest jasna. Różne algorytmy konsensusu i różne wyrafinowane projekty nie są w stanie sprostać systemom stakingu i wielu podpisów, a ten ostatni jest prawdziwym filarem utrzymania działania systemu szyfrowania, na przykład po zdecentralizowanym zastaw WBTC został wycofany, większość BTC L2 nie może istnieć, a rodzime stakowanie Babylonu to eksploracja w tym kierunku, eksploracja warta 70 milionów dolarów amerykańskich.
W tym artykule próbuję nakreślić historię rozwoju technologii szyfrowania, która różni się od różnych zmian technologicznych w branży szyfrowania, takich jak relacje pomiędzy FHE, ZK i MPC. Od zgrubnego procesu aplikacyjnego, na początek stosuje się MPC. FHE Można go zastosować w pośrednim procesie obliczeniowym, a ZK można ostatecznie udowodnić. Pod względem czasu zastosowania ZK był pierwszym, który został wdrożony. Po tym czasie koncepcja portfela AA zyskała popularność jako rozwiązanie techniczne i jego rozwój przyspieszył Dopiero w 2020 r. był FHE. Mówił już o tym Bóg, ale w 2024 r. tylko lekko się zapalił.
MPC/FHE/ZKP
W przeciwieństwie do ZK i MPC, FHE różni się nawet od wszystkich obecnych algorytmów szyfrowania. Z wyjątkiem FHE, każda technologia szyfrowania symetrycznego lub asymetrycznego ma na celu stworzenie „systemu kryptograficznego, którego nie będzie łatwo lub nie da się złamać”, aby osiągnąć absolutność. Jest to bezpieczne, ale. celem FHE jest, aby zaszyfrowany tekst szyfrowany zadziałał, to znaczy szyfrowanie i deszyfrowanie są ważne, ale po zaszyfrowaniu treść przed odszyfrowaniem nie powinna się zmarnować.
Teoria jest kompletna, Web2 został zaimplementowany przed Web3
FHE jest technologią podstawową, a teoretyczne poszukiwania zostały zakończone w kręgach akademickich. W jej rozwój wnieśli ogromny wkład giganci Web2, tacy jak Microsoft, Intel, IBM i Duality wspierane przez DARPA, które przygotowały narzędzia do adaptacji i rozwoju oprogramowania i sprzętu.
Dobra wiadomość jest taka, że giganci Web2 nie wiedzą, co zrobić z FHE. Od teraz nie jest za późno na uruchomienie Web3. Inną złą wiadomością jest to, że adaptacja Web3 wynosi około 0. Główne Bitcoiny i Ethereum Żadne z nich są one natywnie kompatybilne z algorytmem FHE Choć Ethereum jest komputerem świata, to twarde obliczenia FHE prawdopodobnie skończą się wraz z końcem świata.
Koncentrujemy się głównie na eksploracji Web3, pamiętajmy tylko, że giganci Web2 są bardzo entuzjastycznie nastawieni do FHE i wykonali już wiele prac przygotowawczych.
Dzieje się tak, ponieważ w latach 2020–2024 Vitalik skupi się na ZK.
W tym miejscu chciałbym krótko wyjaśnić moje przypisanie popularności ZK. Po tym, jak Ethereum ustanowiło drogę ekspansji Rollup, funkcja kompresji stanu ZK może znacznie zmniejszyć rozmiar danych przesyłanych z L2 do L1, co ma oczywiście wielką wartość ekonomiczną tylko teoretyczne. Zagadnienia takie jak fragmentacja i sortowanie L2, a nawet niektóre kwestie związane z opłatami użytkownika za zbieranie danych L2/Rollup, są nowymi problemami w fazie rozwoju i można je rozwiązać jedynie poprzez dalszy rozwój.
Podsumowując, Ethereum musi zwiększyć swoją pojemność i ustanowić ścieżkę rozwoju Warstwy 2 ZK/OP i Rollup konkurują o doskonałość, tworząc branżowy konsensus krótkoterminowego OP i długoterminowego ZK, kształtując czterech gigantów ARB/. OP/zkSync/SatrkNet.
Ekonomia jest ważnym powodem, a nawet jedynym powodem, dla którego ZK może zostać zaakceptowany przez świat kryptowalut, zwłaszcza system Ethereum. Dlatego też poniższe cechy techniczne FHE nie będą szczegółowo opisywane które FHE może poprawić efektywność operacyjną Web3, lub Aby obniżyć koszty operacyjne Web3, należy zawsze uwzględnić redukcję kosztów i poprawę wydajności.
Krótka historia i osiągnięcia rozwoju FHE
Po pierwsze, należy rozróżnić szyfrowanie homomorficzne od szyfrowania w pełni homomorficznego. Ściśle mówiąc, szyfrowanie w pełni homomorficzne jest szczególnym przypadkiem tego pierwszego. Szyfrowanie homomorficzne oznacza, że „dodawanie lub mnożenie tekstu zaszyfrowanego jest równoznaczne z dodawaniem lub mnożeniem tekstu jawnego”. obliczenie”, czyli:
W tej chwili c i E(c), d i E(d) można uznać za wartości równoważne, ale należy pamiętać, że występują tu dwie trudności:
Równość tekstu jawnego i tekstu zaszyfrowanego faktycznie oznacza, że po dodaniu do tekstu jawnego trochę szumu, tekst zaszyfrowany uzyskuje się wykonując na nim operacje. Jeżeli wartość odchylenia spowodowana tekstem zaszyfrowanym jest zbyt duża, obliczenia się nie udają algorytmy kontrolowania hałasu;
Narzut związany z dodawaniem i mnożeniem jest ogromny, a obliczenie tekstu zaszyfrowanego może być od 10 000 do ponad 1 miliona razy większe niż w przypadku obliczenia tekstu jawnego. Tylko wtedy, gdy można uzyskać jednocześnie nieograniczoną liczbę obliczeń dodawania i mnożenia, można to nazwać szyfrowaniem w pełni homomorficznym. Oczywiście wszystkie rodzaje szyfrowania homomorficznego. Najnowocześniejsze szyfrowanie ma również swoją unikalną wartość w swoich odpowiednich dziedzinach. W zależności od różnych poziomów wdrożenia można je podzielić w następujący sposób:
Szyfrowanie częściowo homomorficzne: na zaszyfrowanych danych można wykonywać tylko ograniczony zestaw operacji, takich jak dodawanie i mnożenie. Szyfrowanie nieco homomorficzne: umożliwia ograniczoną liczbę operacji dodawania i mnożenia.
Szyfrowanie w pełni homomorficzne: umożliwia nieograniczoną liczbę operacji dodawania i mnożenia, umożliwiając w ten sposób dowolne obliczenia na zaszyfrowanych danych.
Rozwój w pełni homomorficznego szyfrowania (FHE) datuje się na rok 2009. Craig Gentry jako pierwszy zaproponował w pełni homomorficzny algorytm oparty na idealnej siatce. Idealna sieć to struktura matematyczna, która pozwala użytkownikom zdefiniować punkt ustawiony w wielowymiarowym układzie przestrzeń, w której te punkty spełniają określoną zależność liniową.
W rozwiązaniu Gentry'ego używana jest idealna krata do reprezentowania kluczowych i zaszyfrowanych danych, dzięki czemu zaszyfrowane dane mogą pozostać prywatne, podczas gdy ładowanie początkowe ma na celu zmniejszenie szumu. Bootstrapping można rozumieć jako „mocne pociąganie za sznurowadła”, „Odwróć się”. w rzeczywistości działa poprzez ponowne szyfrowanie tekstu zaszyfrowanego zaszyfrowanego przez FHE w celu zmniejszenia szumów i zachowania poufności, wspierając w ten sposób złożone operacje obliczeniowe.
Algorytm ten jest kamieniem milowym w FHE. Po raz pierwszy udowodnił on wykonalność FHE w inżynierii, jednak koszt jest ogromny, a obliczenie jednego kroku zajmuje nawet trzydzieści minut. W zasadzie nie ma możliwości praktycznego zastosowania.
Po rozwiązaniu problemu od 0 do 1 pozostaje praktyczność w dużej skali, którą można rozumieć również jako wykonanie odpowiedniego projektu algorytmu w oparciu o różne założenia matematyczne. Oprócz przypadków idealnych stosuje się również LWE (uczenie się z błędem). ze względów bezpieczeństwa) i jego warianty są obecnie najpopularniejszymi rozwiązaniami.
W 2012 roku Zvika Brakerski, Craig Gentry i Vinod Vaikuntanathan zaproponowali schemat BGV, który jest jednym ze schematów FHE drugiej generacji. Jego najważniejszym wkładem jest technologia konwersji analogowo-cyfrowej, która skutecznie kontroluje problemy powodowane przez operacje homomorficzne. Zwiększa się szum zaszyfrowanego tekstu, konstruując w ten sposób poziomowany FHE, to znaczy taki FHE może realizować homomorficzne zadania obliczeniowe na danej głębokości obliczeniowej.
Podobne rozwiązania obejmują BFV i CKKS. W szczególności rozwiązanie CKKS może obsługiwać operacje zmiennoprzecinkowe, ale jeszcze bardziej zwiększy zużycie zasobów obliczeniowych, a wciąż potrzebne są lepsze rozwiązania.
Wreszcie istnieją schematy TFHE i FHEW, zwłaszcza schemat TFHE, który jest preferowanym algorytmem Zamy. Krótko go przedstawiamy, problem szumów FHE można zmniejszyć poprzez ładowanie zastosowane po raz pierwszy przez Gentry'ego i TFHE. może to zrobić. Efektywne ładowanie i gwarantowana dokładność, więc ma dobry punkt integracji z polem blockchain.
Właśnie przedstawiliśmy każde rozwiązanie. W rzeczywistości różnica między nimi nie polega na zaletach i wadach, ale raczej na różnych scenariuszach. Jednakże zasadniczo wymagają one silnego wsparcia w zakresie oprogramowania i sprzętu. Nawet rozwiązanie TFHE musi również rozwiązać problem sprzętowy Problem można zastosować jedynie na dużą skalę. W zasadzie nie da się podążać ścieżką „najpierw algorytmy i oprogramowanie, a potem hardware i modularyzacja” w dziedzinie ZK. Oznacza to, że FHE musi rozwijać się jednocześnie ze sprzętem początek, przynajmniej w dziedzinie szyfrowania.
Web 2 OpenFHE kontra Web3 Zama
Jak wspomniano wcześniej, wszyscy giganci Web2 eksplorują i osiągnęli pewne praktyczne wyniki. Tutaj podsumowujemy je i przedstawiamy scenariusze zastosowań Web3.
Aby uprościć sprawę, IBM udostępnił bibliotekę Helib, która obsługuje głównie BGV i CKKS. Biblioteka Microsoftu SEAL obsługuje głównie rozwiązania CKKS i BFV. Warto wspomnieć, że Song Yongsoo, jeden z autorów CKKS, brał udział w projektowaniu i rozwoju SEAL. , a OpenFHE to najbardziej zaawansowany Master, opracowany przez Duality wspierany przez DARPA, obsługuje obecnie główne algorytmy, takie jak BGV, BFV, CKKS, TFHE i FHEW. Szacuje się, że jest to najbardziej kompletna istniejąca biblioteka FHE na rynku.
Co więcej, OpenFHE zbadało również współpracę z biblioteką akceleracji procesorów Intela i wywołało interfejs CUDA firmy NVIDIA w celu obsługi akceleracji GPU. Jednak najnowsze wsparcie CUDA dla FHE miało miejsce w 2018 roku i nie znaleziono jeszcze żadnego zaktualizowanego wsparcia. proszę mnie poprawić.
OpenFHE obsługuje C++ i Python, interfejs API Rust jest w fazie rozwoju i ma na celu zapewnienie prostej i wszechstronnej modularyzacji oraz możliwości międzyplatformowych. Jeśli jesteś programistą Web2, jest to najłatwiejsze, gotowe do użycia rozwiązanie.
Jeśli jesteś programistą Web3, będzie to trudniejsze.
Ograniczona słabą mocą obliczeniową większość sieci publicznych nie jest w stanie obsłużyć wykonania algorytmu FHE. Po drugie, w ekologii Bitcoina i Ethereum brakuje obecnie „popytu ekonomicznego” na FHE. Ponownie podkreśla się, że po pierwsze istnieje potrzeba L2--> L1 Potrzeba sprawnej transmisji danych zainspirowała wdrożenie algorytmu ZK, którego nie można stosować na rzecz FHE. Jest to wbijanie gwoździ i wymuszenie dopasowywania, co tylko zwiększy koszt wdrożenia.
Jak działa FHE+EVM
Poniższy artykuł szczegółowo opisuje napotkane trudności i możliwe scenariusze implementacji. Artykuł ten daje głównie pewność programistom Web3.
W 2024 r. Zama otrzymała największe finansowanie koncepcji FHE w dziedzinie szyfrowania, w wysokości 73 mln USD, na czele którego stoi Multicoin. Zama posiada obecnie głównie bibliotekę algorytmów opartą na TFHE, a następnie fhEVM, która wspiera rozwój łańcuchów kompatybilnych z EVM z funkcjami FHE. na tym.
Po drugie, istnieje problem wydajności, który można rozwiązać jedynie poprzez współpracę oprogramowania i sprzętu. Jednym z nich jest to, że EVM nie może bezpośrednio obsługiwać kontraktu FHE. Nie stoi to w sprzeczności z rozwiązaniem fhEVM firmy Zama, które stworzyło własny łańcuch. który może bezpośrednio dodać funkcję FHE natywnie. Na przykład Shiba Inu chce również zbudować warstwę 3 w oparciu o rozwiązanie Zama. Dla nowo utworzonego łańcucha obsługa FHE jest trudna. Trudność ma samo Ethereum EVM możliwość wdrażania kontraktów FHE Wymaga to obsługi kodu operacyjnego (kodu operacyjnego) Ethereum. Dobra wiadomość. Fair Math i OpenFHE wspólnie zorganizowały konkurs FHERMA, aby zachęcić programistów do przepisania kodu operacyjnego EVM, co można uznać za aktywne badanie możliwości kombinacji.
Drugim jest akceleracja sprzętowa. Można powiedzieć, że nawet jeśli wysokowydajne sieci publiczne, takie jak Solana, natywnie obsługują wdrażanie kontraktów FHE, ich węzły zostaną przeciągnięte na śmierć. Natywny sprzęt FHE obejmuje głównie 3PU™ (jednostkę przetwarzania ochrony prywatności) firmy Chain Reaction ), czyli układ ASIC. Po drugie, Zama lub Inco również badają możliwość akceleracji sprzętowej. Na przykład obecny TPS Zamy wynosi około 5, Inco może osiągnąć 10 TPS, a Inco uważa, że przy użyciu akceleracji sprzętowej FPGA można przyspieszyć TPS. do około 100-1000.
Jednak nie ma potrzeby zbytnio martwić się kwestią szybkości. Istniejące rozwiązanie akceleracji sprzętowej ZK można teoretycznie zmodyfikować w celu dostosowania do rozwiązania FHE. Dlatego też poniższe omówienie nie będzie nadmiernie skupiać się na problemie szybkości, ale skupi się głównie na scenariuszach i rozwiązuje problemy z adaptacją EVM.
Dark Pool i Jade nie żyją, FHE X Crypto ma przed sobą świetlaną przyszłość
Kiedy Multicoin prowadził inwestycję w Zama, mówiono, że ZKP to przeszłość, a przyszłość należy do FHE. Czy przyszłość się spełni, zawsze będzie trudne. Po Zamie Inco Network i Fhenix utworzyły niewidzialny sojusz ekologiczny fhEVM swój własny cel i ścieżkę. Zasadniczo taki sam, to znaczy zaangażowany w integrację ekologii FHE i EVM.
Lepiej zrobić to wcześniej niż później. Zacznijmy od miski z zimną wodą.
Rok 2024 może być ważnym rokiem dla FHE, ale Elusiv, którego działalność rozpoczęła się w 2022 r., zakończył działalność. Pierwotnie Elusiv był protokołem „dark Pool” na platformie Solana, a obecnie baza kodu i dokumentacja zostały usunięte.
W końcu FHE, jako część komponentów technicznych, nadal musi być używany razem z technologiami takimi jak MPC/ZKP i musimy zbadać, w jaki sposób FHE może zmienić obecny paradygmat blockchainu.
Przede wszystkim musimy przyznać, że niewłaściwie jest po prostu sądzić, że FHE zwiększy prywatność, a zatem będzie miała wartość ekonomiczną. Sądząc z dotychczasowej praktyki, użytkownicy Web3 lub on-chain nie przejmują się zbytnio prywatnością i będą korzystać tylko z istotnych informacji narzędzia, w których prywatność może zapewnić wartość ekonomiczną, np. hakerzy będą używać Tornado Cash w celu ukrycia skradzionych środków, podczas gdy zwykli użytkownicy będą korzystać wyłącznie z Uniswap, ponieważ korzystanie z Tornado Cash będzie wymagało dodatkowego czasu lub kosztów ekonomicznych.
Koszt szyfrowania FHE sam w sobie jest kolejną torturą i tak już słabej wydajności operacyjnej w łańcuchu. Dopiero gdy ten wzrost kosztów przyniesie bardziej znaczące korzyści, czy można promować ochronę prywatności na dużą skalę, na przykład w kierunku RWA? Emisja i obrót obligacjami Na przykład w czerwcu 2023 r. Bank of China International wyemitował „Cyfrowe obligacje strukturyzowane Blockchain” klientom z regionu Azji i Pacyfiku w Hongkongu za pośrednictwem UBS i w komunikacie prasowym UBS wskazał, że odbywało się to za pośrednictwem Ethereum, ale magicly Nie udało się znaleźć adresu umowy ani adresu dystrybucji transakcji. Jeśli ktoś może go odnaleźć, proszę o dodanie odpowiednich informacji.
Ten przykład może jasno zilustrować znaczenie FHE Dla klientów instytucjonalnych, którzy mają potrzebę korzystania z łańcuchów publicznych, takich jak blockchain, ale nie są odpowiedni lub chcą ujawnić wszystkie informacje, FHE może wyświetlić zaszyfrowany tekst i bezpośrednio Charakterystykę operacji, takich jak zakup i. sprzedaż będzie bardziej odpowiednia niż ZKP.
Dla indywidualnych inwestorów detalicznych FHE jest wciąż stosunkowo odległą bazową infrastrukturą. Mogę wymienić kilka kierunków, takich jak anty-MEV, transakcje prywatne, bezpieczniejsze sieci, zapobieganie szpiegowaniu przez osoby trzecie itp., ale oczywiście nie są to pierwsze -zapotrzebowanie czasowe, a użycie FHE teraz rzeczywiście spowolni sieć. Lepiej szczerze powiedzieć, że główny moment FHE jeszcze nie nadszedł.
Podsumowując, prywatność jest banalną potrzebą. Jako usługa publiczna niewiele osób jest skłonnych płacić za prywatność wyższą cenę. Musimy znaleźć scenariusze, w których właściwości obliczeniowe danych zaszyfrowanych przez FHE mogą w ten sposób obniżyć koszty lub poprawić efektywność transakcji tworzenie rynku Spontaniczny impuls. Na przykład istnieje wiele rozwiązań przeciwdziałających MEV. Na przykład scentralizowane węzły mogą faktycznie rozwiązać ten problem.
Kolejnym problemem jest kwestia wydajności obliczeniowej. Z pozoru jest to kwestia techniczna wymagająca akceleracji sprzętowej lub optymalizacji algorytmu, jednak w istocie na rynku nie ma dużego zapotrzebowania, a strona projektowa nie ma motywacji, aby to poprawić. Ostatecznie wdrożono wydajność obliczeniową. Weźmy jako przykład ZK. W obliczu rosnącego popytu na rynku trasy SNARK i STARK konkurują ze sobą. Różne pakiety ZK Rollup ciężko pracowały nad rozwojem z języków programowania do kompatybilności Rozwój ZK został przyspieszony przez gorące pieniądze.
Scenariusze zastosowań i wdrożenia są przełomem dla FHE, aby stać się infrastrukturą blockchain. Jeśli nie uda mu się wykonać tego kroku, FHE nigdy nie będzie w stanie nabrać rozpędu w branży szyfrowania, a główne strony projektu będą mogły jedynie bawić się na uboczu i pracować. po prostu się bawiłem.
Sądząc po praktyce Zamy i jego przyjaciół, konsensus polega na zbudowaniu nowego łańcucha poza Ethereum i ponownym wykorzystaniu w nim komponentów technicznych i standardów, takich jak ERC-20, w celu utworzenia schematu szyfrowania dla FHE L1/L2 w celu połączenia z Ethereum This Zaletą tego rozwiązania jest to, że można je najpierw wypróbować i zbudować podstawowe komponenty FHE. Wadą jest to, że jeśli samo Ethereum nie obsługuje algorytmu FHE, to rozwiązanie off-chain zawsze będzie w kłopotliwej sytuacji.
Sama Zama jest również świadoma tego problemu. Oprócz wspomnianych powyżej bibliotek zajęć związanych z FHE, uruchomiła także organizację FHE.org i sponsorowała odpowiednie konferencje, mając nadzieję na przekształcenie większej liczby wyników akademickich w zastosowania inżynieryjne.
Kierunkiem rozwoju Inco Network jest „uniwersalna warstwa obliczeniowa prywatności”, która w istocie jest modelem dostawcy usług outsourcingu obliczeniowego. Buduje sieć FHE EVM L1 w oparciu o Zama. Ciekawym eksploracją jest współpraca z protokołem przesyłania wiadomości między łańcuchami Hyperlane zintegrować inny Mechanizm gry w łańcuchu zgodnym z EVM jest wdrożony w Inco. Gdy podczas działania gry wymagane jest obliczenie FHE, moc obliczeniowa Inco jest wywoływana przez Hyperlane, a następnie tylko wyniki są przesyłane z powrotem do oryginalnego łańcucha.
Aby zrealizować scenariusz przewidziany przez Inco, konieczne jest, aby łańcuch zgodny z EVM był skłonny zaufać reputacji Inco, a moc obliczeniowa Inco musi być wystarczająco duża, aby naprawdę dobrze radziła sobie z wymaganiami łańcucha dotyczącymi dużej współbieżności i małych opóźnień gry? Operacje są dość trudne.
Co za tym idzie, niektóre maszyny zkVM mogą faktycznie pełnić rolę outsourcingu obliczeniowego FHE. Na przykład RISC Zero ma już taką możliwość. Kolejna kolizja pomiędzy produktami serii ZK i FHE może wywołać więcej iskier.
Co więcej, niektóre projekty mają nadzieję zbliżyć się nieco do Ethereum, przynajmniej zmierzając w kierunku stania się częścią Ethereum. Inco może wykorzystać rozwiązanie Zama do wdrożenia L1, a Fhenix może wykorzystać rozwiązanie Zama do wdrożenia EVM L2, które jest wciąż w fazie rozwoju. , wydaje się, że chce podążać w wielu kierunkach. Nie wiem, jaki produkt ostatecznie zostanie wdrożony. Być może będzie to L2 skupiający się na możliwościach FHE.
Dodatkowo istnieje wspomniany wyżej konkurs FHERMA. Czytelnicy będący programistami biegłymi w rozwoju Ethereum mogą w nim uczestniczyć. Mogą pomóc we wdrożeniu FHE i jednocześnie zyskać bonusy.
Ponadto istnieją dwa inne niesamowite projekty, Sunscreen i Mind Network. Sunscreen jest obsługiwany głównie przez samą firmę Ravital. Kierunek jest taki, aby użyć algorytmu BFV do stworzenia rozwiązania kompilującego odpowiedniego dla FHE i eksperymentowania przez długi czas i nadal jest daleki od praktycznego zastosowania. Zajmie to trochę czasu.
Wreszcie, pomysły Mind Network skupiają się głównie na połączeniu FHE i różnych istniejących scenariuszy, takich jak ponowne obstawianie, ale sprawdzenie, jak konkretnie to wdrożyć, zajmie trochę czasu.
Na koniec, aby przypomnieć początek tej sekcji, Elusiv zmienił teraz nazwę na Arcium, otrzymał także nowe finansowanie i przekształcił się w rozwiązanie „równoległe FHE”, które ma ulepszyć FHE z punktu widzenia efektywności wykonawczej.
Wniosek
Artykuł ten wydaje się mówić o teorii i praktyce FHE, ale ukrytym założeniem jest wyjaśnienie historii rozwoju samej technologii szyfrowania. Nie jest to całkowicie równoważne technologii stosowanej w kryptowalutach. ZKP i FHE mają wiele podobieństw, jedno z nich czyli do czego oboje się zobowiązali. Aby zachować projekt prywatności przy jednoczesnym zachowaniu publicznego charakteru blockchainu, rozwiązanie w zakresie prywatności ZKP nakierowane jest na zmniejszenie kosztów ekonomicznych interakcji pomiędzy L2 <> L1, podczas gdy FHE wciąż szuka swojego własny najlepszy scenariusz.
Rodzaje planów
Przed nami długa droga, a FHE wciąż prowadzi badania. Można go podzielić na trzy typy w zależności od stopnia połączenia z Ethereum:
Typ 1: Niezależne królestwo, komunikujące się z eterem. Reprezentowana przez sieć Zama/Fhenix/Inco, dostarcza głównie podstawowe komponenty rozwojowe i zachęca do samodzielnej budowy FHE L1/L2, która jest odpowiednia dla niektórych segmentów;
Typ 2: Podłącz i zintegruj z siecią Ethernet. Reprezentowany przez Fair Math/Mind Network, choć zachowuje pewien stopień niezależności, ogólną ideą jest osiągnięcie głębszej integracji z Ethereum.
Typ 3: Spotkajcie się i przekształćcie eter. Jeśli Ethereum nie może natywnie obsługiwać funkcji FHE, należy zbadać ją na poziomie kontraktu w celu dystrybucji funkcji FHE do różnych łańcuchów kompatybilnych z EVM. Obecnie nie ma rozwiązania, które w pełni spełniałoby ten standard.
W przeciwieństwie do ZK, który na późniejszych etapach rozwoju widział tylko łańcuch FHE i akcelerację sprzętową, FHE stoi na barkach gigantów ZK. Teraz może najłatwiej jest wysłać łańcuch FHE, ale jak komunikować się między sobą a Ethereum jest najtrudniejsze.
Badaj się trzy razy dziennie i szukaj przyszłych współrzędnych FHE w świecie blockchain:
Jakie scenariusze muszą być zaszyfrowane i nie można używać zwykłego tekstu?
Jakie scenariusze wymagają szyfrowania FHE, ale nie można zastosować innych metod szyfrowania?
Jakie scenariusze sprawiłyby, że użytkownicy czuliby się dobrze, korzystając z szyfrowania FHE i byliby skłonni zapłacić więcej?
Aby kontynuować, będę nadal zwracać uwagę na FHE!
