Budowanie Helios: Całkowicie nieufny dostęp do Ethereum

Jednym z głównych powodów, dla których korzystamy z blockchainów, jest brak zaufania. Ta właściwość obiecuje umożliwić nam samodzielny dostęp do naszego bogactwa i danych. W większości blockchainy, takie jak Ethereum, spełniły tę obietnicę — nasze aktywa są naprawdę nasze. 

Są jednak ustępstwa, które poczyniliśmy ze względu na wygodę. Jednym z takich obszarów jest wykorzystanie przez nas scentralizowanych serwerów RPC (zdalnego wywoływania procedur). Użytkownicy zazwyczaj uzyskują dostęp do Ethereum za pośrednictwem scentralizowanych dostawców, takich jak Alchemy. Firmy te prowadzą wysokowydajne węzły na serwerach w chmurze, aby inni mogli łatwo uzyskać dostęp do danych łańcucha. Kiedy portfel pyta o saldo swoich tokenów lub sprawdza, czy oczekująca transakcja została uwzględniona w bloku, prawie zawsze robi to za pośrednictwem jednego z tych scentralizowanych dostawców. 

Kłopot z istniejącym systemem polega na tym, że użytkownicy muszą ufać dostawcom i nie ma możliwości zweryfikowania poprawności ich zapytań.

Wchodzę Helios, opracowany przez nas lekki klient Ethereum oparty na Ruście, który zapewnia w pełni nieufny dostęp do Ethereum. Helios — który wykorzystuje lekki protokół klienta Ethereum, co jest możliwe dzięki ostatnia zmiana do dowód stawki — przekształca dane pochodzące od niezaufanego scentralizowanego dostawcy RPC w dające się zweryfikować bezpieczne, lokalne RPC. Helios współpracuje ze scentralizowanymi RPC, aby umożliwić weryfikację ich autentyczności bez uruchamiania pełnego węzła. 

Kompromis między przenośnością a decentralizacją jest powszechnym problemem, ale nasz klient – ​​który udostępniliśmy publicznie do budowania i więcej – synchronizuje się w około dwie sekundy, nie wymaga pamięci masowej i umożliwia użytkownikom dostęp do bezpiecznych danych łańcucha z dowolne urządzenie (w tym telefony komórkowe i rozszerzenia przeglądarki). Ale jakie są? potencjalne pułapki polegania na scentralizowanej infrastrukturze? W tym poście opisujemy, jak mogą się rozegrać, omawiamy nasze decyzje projektowe, a także przedstawiamy kilka pomysłów, które inni mogą wnieść do baza kodów.

Pułapki scentralizowanej infrastruktury: teoretyczne stworzenia w „mrocznym lesie” Ethereum

(Teoretyczna) istota czai się w ciemny las. Ten nie poluje na swoją zdobycz w pamięci Ethereum, ale zamiast tego zastawia pułapki, naśladując scentralizowaną infrastrukturę, na której polegamy. Użytkownicy, którzy wpadną w tę pułapkę, nie popełniają błędów: odwiedzają swoją ulubioną zdecentralizowaną giełdę, ustawiają rozsądną tolerancję na poślizgi oraz jak zwykle kupują i sprzedają tokeny… Robią wszystko dobrze, ale wciąż padają ofiarą nowego rodzaju atak kanapkowy, pułapka skrupulatnie zastawiona na samym wejściu do mrocznego lasu Ethereum: dostawcy RPC.

Zanim przejdziemy dalej, spójrzmy, jak działają transakcje na zdecentralizowanych giełdach. Kiedy użytkownicy wysyłają transakcję swap, dostarczają do inteligentnego kontraktu kilka parametrów — które tokeny do wymiany, kwotę swapu i, co najważniejsze, minimalną liczbę tokenów, które użytkownik musi otrzymać, aby transakcja mogła przejść. Ten ostatni parametr określa, że ​​zamiana musi spełniać „minimalne wyjście” lub odwrócić. Jest to często znane jako „tolerancja poślizgu”, ponieważ skutecznie określa maksymalną zmianę ceny, która może wystąpić między momentem wysłania transakcji do mempool a włączeniem jej do bloku. Jeśli ten parametr jest ustawiony zbyt nisko, użytkownik akceptuje możliwość otrzymania mniejszej liczby tokenów. Ta sytuacja może również prowadzić do ataku typu sandwich, w którym atakujący skutecznie umieszcza ofertę między dwiema złośliwymi zamianami. Swapy podnoszą cenę spot i zmuszają użytkownika do realizacji transakcji po mniej korzystnej cenie. Atakujący następnie natychmiast sprzedaje, aby uzyskać niewielki zysk.

Dopóki ten minimalny parametr wyjściowy jest ustawiony w pobliżu wartości godziwej, jesteś bezpieczny przed atakami typu sandwich. Ale co, jeśli Twój dostawca RPC nie przedstawi dokładnej wyceny ze zdecentralizowanej inteligentnej umowy wymiany? Użytkownik może następnie zostać nakłoniony do podpisania transakcji wymiany z niższym minimalnym parametrem wyjściowym, a co gorsza, wysłać transakcję bezpośrednio do złośliwego dostawcy RPC. Zamiast rozgłaszać tę transakcję do publicznej pamięci, gdzie dziesiątki botów konkurują o przeprowadzenie ataku typu sandwich, dostawca może wstrzymać tę transakcję i wysłać pakiet transakcji ataku bezpośrednio do Flashbotów, zapewniając sobie zyski.

Główną przyczyną tego ataku jest zaufanie, że ktoś inny pobierze stan łańcucha bloków. Doświadczeni użytkownicy tradycyjnie rozwiązywali ten problem, uruchamiając własne węzły Ethereum — przedsięwzięcie wymagające dużej ilości czasu i zasobów, które wymaga co najmniej stale działającej maszyny, setek gigabajtów pamięci i około jednego dnia synchronizacji od zera. Ten proces jest z pewnością łatwiejszy niż kiedyś; grupy takie jak Ethereum na ARM pracowali niestrudzenie, aby umożliwić uruchamianie węzłów na tanim sprzęcie (takim jak Raspberry Pi z podłączonym do niego zewnętrznym dyskiem twardym). Ale nawet przy tych stosunkowo minimalnych wymaganiach uruchomienie węzła jest nadal trudne dla większości użytkowników, szczególnie tych korzystających z urządzeń mobilnych.

Należy zauważyć, że ataki scentralizowanych dostawców RPC, choć całkowicie prawdopodobne, są generalnie: proste ataki phishingowe — a ten, który opisujemy, jeszcze się nie wydarzył. Mimo że osiągnięcia większych dostawców, takich jak Alchemy, nie dają nam powodów, by w nie wątpić, warto przeprowadzić dalsze badania przed dodaniem nieznanych dostawców RPC do portfela.

Przedstawiamy Helios: w pełni nieufny dostęp do Ethereum

Wprowadzając swój lekki protokół kliencki (możliwy dzięki niedawnemu przejściu na Proof of Stake), Ethereum otworzył ekscytujące nowe możliwości szybkiej interakcji z blockchainem i weryfikacji punktów końcowych RPC przy minimalnych wymaganiach sprzętowych. W miesiącu od Scalanie, zaobserwowaliśmy, jak nowa liczba lekkich klientów pojawia się niezależnie od siebie (Lodestar, nimbi oparty na języku JavaScript Kevlar), które przyjęły różne podejścia w celu realizacji tego samego celu: wydajnego i nieufnego dostępu bez korzystania z pełnego węzła.

Nasze rozwiązanie, Helios, jest lekkim klientem Ethereum, który synchronizuje się w około dwie sekundy, nie wymaga pamięci masowej i zapewnia w pełni niezaufany dostęp do Ethereum. Podobnie jak wszyscy klienci Ethereum, Helios składa się z warstwy wykonawczej i warstwy konsensusu. W przeciwieństwie do większości innych klientów, Helios ściśle łączy obie warstwy, dzięki czemu użytkownicy muszą instalować i uruchamiać tylko jedno oprogramowanie. (Erygon również zmierza w tym kierunku, dodając lekkiego klienta warstwy konsensusu wbudowanego bezpośrednio w węzeł archiwum). 

Więc jak to działa? Warstwa konsensusu Helios używa znanego wcześniej blockhash łańcucha sygnałów nawigacyjnych i połączenia z niezaufanym RPC, aby zweryfikować synchronizację z bieżącym blokiem. Warstwa wykonania Helios wykorzystuje te uwierzytelnione bloki łańcucha sygnałów nawigacyjnych w połączeniu z niezaufanym RPC warstwy wykonawczej w celu udowodnienia dowolnych informacji o stanie łańcucha, takich jak salda kont, przechowywanie umów, pokwitowania transakcji i wyniki wywoływania inteligentnych umów. Te składniki współpracują ze sobą, aby zapewnić użytkownikom w pełni niezaufane RPC, bez konieczności uruchamiania pełnego węzła.

…W warstwie konsensusu

Klient światła warstwy konsensusu jest zgodny z klientem światła łańcucha sygnałów nawigacyjnych specyfikacja, i korzysta z komitetów synchronizacji łańcucha sygnałów nawigacyjnych (wprowadzonych przed połączeniem w hard forku Altair). Komitet synchronizacji to losowo wybrany podzbiór 512 walidatorów, które działają przez około 27 godzin. 

Gdy walidator jest w komitecie synchronizacji, podpisuje każdy nagłówek bloku łańcucha beaconów, który widzi. Jeśli więcej niż dwie trzecie komitetu podpisuje dany nagłówek bloku, jest wysoce prawdopodobne, że blok ten znajduje się w kanonicznym łańcuchu sygnałów nawigacyjnych. Jeśli Helios zna skład obecnego komitetu synchronizacji, może bez obaw śledzić szefa łańcucha, prosząc niezaufanego RPC o najnowszy podpis komitetu synchronizacji. 

Dzięki BLS podpis agregacja, tylko jedno sprawdzenie jest wymagane do zweryfikowania nowego nagłówka. Jeśli podpis jest ważny i został podpisany przez więcej niż dwie trzecie komitetu, można bezpiecznie założyć, że blok został włączony do łańcucha (oczywiście można go ponownie uporządkować poza łańcuch, ale ostateczność bloku śledzenia może zapewnić bardziej rygorystyczne gwarancje).

W tej strategii jest jednak oczywisty brakujący element: jak znaleźć obecny komitet synchronizacji. Zaczyna się od zdobycia korzenia zaufania zwanego słaby punkt kontrolny subiektywności. Nie daj się zastraszyć tej nazwie — oznacza to po prostu stary blockhash, co do którego możemy zagwarantować, że znalazł się w łańcuchu w pewnym momencie w przeszłości. Za tym, ile dokładnie lat może mieć punkt kontrolny, kryje się interesująca matematyka; Analiza najgorszego przypadku sugeruje około dwóch tygodni, podczas gdy bardziej praktyczne szacunki sugerują wiele miesięcy. 

Jeśli punkt kontrolny jest zbyt stary, są ataki teoretyczne które mogą skłonić węzły do ​​podążania za niewłaściwym łańcuchem. Uzyskanie słabego punktu kontrolnego subiektywności jest poza pasmem dla protokołu. Nasze podejście z Helios zapewnia początkowy punkt kontrolny zakodowany na sztywno w bazie kodu (który można łatwo nadpisać); następnie zapisuje lokalnie najnowszy sfinalizowany blockhash, aby użyć go jako punktu kontrolnego w przyszłości, za każdym razem, gdy węzeł zostanie zsynchronizowany. 

Dogodnie, bloki łańcucha beaconów można zahaszować w celu wytworzenia unikalnego haszowania beacon blockhash. Oznacza to, że łatwo jest poprosić węzeł o pełny blok sygnału nawigacyjnego, a następnie udowodnić, że zawartość bloku jest poprawna, mieszając go i porównując ze znanym blockhashem. Helios używa tej właściwości do pobierania i udowadniania pewnych pól w bloku punktu kontrolnego słabej podmiotowości, w tym dwóch bardzo ważnych pól: bieżącego komitetu synchronizacji i następnego komitetu synchronizacji. Co najważniejsze, ten mechanizm umożliwia lekkim klientom szybkie przewijanie historii łańcucha bloków.

Teraz, gdy mamy słaby punkt kontrolny subiektywności, możemy pobrać i zweryfikować obecny i następny komitet synchronizacji. Jeśli bieżący nagłówek łańcucha znajduje się w tym samym okresie komitetu synchronizacji, co punkt kontrolny, natychmiast zaczynamy weryfikować nowe bloki za pomocą podpisanych nagłówków komitetu synchronizacji. Jeśli nasz punkt kontrolny jest za kilkoma komitetami synchronizacji, możemy:

1. Użyj następnego komitetu synchronizacji po naszym punkcie kontrolnym, aby pobrać i zweryfikować blok, który w przyszłości pochodzi z jednego komitetu synchronizacji.
2. Użyj tego nowego bloku, aby pobrać nowy następny komitet synchronizacji.
3. Jeśli nadal jesteś w tyle, wróć do kroku 1.

Każda iteracja tego procesu pozwala nam szybko przewinąć do przodu 27 godzin historii łańcucha, rozpocząć od dowolnego blockhash w przeszłości i zsynchronizować z bieżącym blockhashem.

…W warstwie wykonawczej

Celem klienta lekkiego warstwy wykonawczej jest pobieranie nagłówków bloków sygnału nawigacyjnego, które są weryfikowane przez warstwę konsensusu, i używanie ich wraz z niezaufanym RPC warstwy wykonawczej w celu dostarczenia zweryfikowanych danych warstwy wykonawczej. Dostęp do tych danych można następnie uzyskać za pośrednictwem serwera RPC hostowanego lokalnie przez firmę Helios.

Oto prosty przykład pobierania salda konta, zaczynając od szybkiego wprowadzenia do tego, jak stan jest przechowywany w Ethereum. Każde konto zawiera kilka pól, takich jak skrót kodu umowy, wartość jednorazowa, skrót magazynu i saldo. Konta te są przechowywane w dużej, zmodyfikowanej Drzewo Merkle-Patricia zwany drzewem stanu. Jeśli znamy korzeń drzewa stanów, możemy sprawdzić poprawność merkle dowody udowodnić istnienie (lub wykluczenie) dowolnego konta w drzewie. Te dowody są praktycznie niemożliwe do podrobienia.

Helios ma uwierzytelniony katalog główny stanu z warstwy konsensusu. Korzystanie z tego korzenia i Merkle dowód żądania do niezaufanego RPC warstwy wykonawczej, Helios może lokalnie weryfikować wszystkie dane przechowywane w Ethereum.

Stosujemy różne techniki weryfikacji wszelkiego rodzaju danych wykorzystywanych przez warstwę wykonawczą; używane razem, umożliwiają nam uwierzytelnienie wszystkich danych pobranych z niezaufanego RPC. Chociaż niezaufane RPC może odmówić dostępu do danych, nie może już podawać nam nieprawidłowych wyników.

Używanie Helios na wolności

Kompromis między przenośnością a decentralizacją jest powszechnym problemem — ale ponieważ Helios jest tak lekki, użytkownicy mogą uzyskać dostęp do bezpiecznych danych łańcucha z dowolnego urządzenia (w tym telefonów komórkowych i rozszerzeń przeglądarki). Możliwość uruchomienia Helios w dowolnym miejscu umożliwia większej liczbie osób dostęp do danych Ethereum bez zaufania, niezależnie od ich sprzętu. Oznacza to, że użytkownicy mogą używać Helios jako dostawcy RPC w MetaMask i bez zaufania uzyskiwać dostęp do dappów bez żadnych innych zmian. 

Co więcej, wsparcie Rusta dla WebAssembly ułatwia twórcom aplikacji osadzenie Helios w aplikacjach JavaScript (takich jak portfele i dappy). Te integracje sprawią, że Ethereum będzie bezpieczniejsze i zmniejszy naszą potrzebę zaufania do scentralizowanej infrastruktury.

Nie możemy się doczekać, aby zobaczyć, co wymyśli społeczność. Ale w międzyczasie istnieje wiele sposobów, aby wnieść wkład w Helios — jeśli nie jesteś zainteresowany współpracą z bazą kodu, możesz również zbudować oprogramowanie, które integruje Helios, aby czerpać korzyści z jego zalet. To tylko kilka pomysłów, którymi jesteśmy podekscytowani:

• Obsługa pobierania lekkich danych klienta bezpośrednio z sieci P2P, a nie przez RPC
• Zaimplementuj niektóre z brakujących metod RPC
• Zbuduj wersję Helios, która skompiluje się do WebAssembly
• Zintegruj Helios bezpośrednio z oprogramowaniem portfela
• Zbuduj internetowy pulpit nawigacyjny, aby wyświetlić salda tokenów, który pobiera dane z Helios osadzone na stronie internetowej za pomocą WebAssembly
• Zaimplementuj interfejs API silnika, aby warstwa konsensusu Helios mogła być połączona z istniejącym pełnym węzłem warstwy wykonawczej

Sprawdź bazę kodów na początek — czekamy na Twoje zgłoszenia błędów, prośby o nowe funkcje i kod. A jeśli zbudujesz coś więcej, podziel się tym z nami dalej Twitter, Telegramlub Farcaster @a16zcrypto.

***
Wyrażone tutaj poglądy są poglądami poszczególnych cytowanych pracowników AH Capital Management, LLC („a16z”) i nie są poglądami a16z ani jej podmiotów stowarzyszonych. Niektóre informacje w nim zawarte zostały pozyskane ze źródeł zewnętrznych, w tym od spółek portfelowych funduszy zarządzanych przez a16z. Chociaż pochodzą ze źródeł uważanych za wiarygodne, a16z nie zweryfikowało niezależnie takich informacji i nie składa żadnych oświadczeń dotyczących aktualnej lub trwałej dokładności informacji lub ich adekwatności w danej sytuacji. Ponadto treści te mogą zawierać reklamy osób trzecich; a16z nie przeglądał takich reklam i nie popiera żadnych zawartych w nich treści reklamowych.

Te treści są udostępniane wyłącznie w celach informacyjnych i nie należy ich traktować jako porady prawnej, biznesowej, inwestycyjnej lub podatkowej. Powinieneś skonsultować się w tych sprawach z własnymi doradcami. Odniesienia do jakichkolwiek papierów wartościowych lub aktywów cyfrowych służą wyłącznie celom ilustracyjnym i nie stanowią rekomendacji inwestycyjnej ani oferty świadczenia usług doradztwa inwestycyjnego. Ponadto treść ta nie jest skierowana ani przeznaczona do użytku przez jakichkolwiek inwestorów lub potencjalnych inwestorów iw żadnym wypadku nie można na nich polegać przy podejmowaniu decyzji o zainwestowaniu w jakikolwiek fundusz zarządzany przez a16z. (Oferta inwestycji w fundusz a16z zostanie złożona wyłącznie na podstawie memorandum dotyczącego oferty prywatnej, umowy subskrypcyjnej i innej odpowiedniej dokumentacji takiego funduszu i należy ją przeczytać w całości.) Wszelkie inwestycje lub spółki portfelowe wymienione, wymienione lub opisane nie są reprezentatywne dla wszystkich inwestycji w pojazdy zarządzane przez a16z i nie można zapewnić, że inwestycje będą opłacalne lub że inne inwestycje dokonane w przyszłości będą miały podobne cechy lub wyniki. Lista inwestycji dokonanych przez fundusze zarządzane przez Andreessena Horowitza (z wyłączeniem inwestycji, w przypadku których emitent nie wyraził zgody na publiczne ujawnienie przez a16z oraz niezapowiedzianych inwestycji w aktywa cyfrowe będące w obrocie publicznym) jest dostępna pod adresem https://a16z.com/investments /.

Wykresy i wykresy zamieszczone w niniejszym dokumencie służą wyłącznie celom informacyjnym i nie należy na nich polegać przy podejmowaniu jakichkolwiek decyzji inwestycyjnych. Wyniki osiągnięte w przeszłości nie wskazują na przyszłe wyniki. Treść mówi dopiero od wskazanej daty. Wszelkie prognozy, szacunki, prognozy, cele, perspektywy i/lub opinie wyrażone w tych materiałach mogą ulec zmianie bez powiadomienia i mogą się różnić lub być sprzeczne z opiniami wyrażanymi przez innych. Dodatkowe ważne informacje można znaleźć na stronie https://a16z.com/disclosures