Wyjaśnienie zarządzania głównym protokołem Ethereum

Prezentacja Nixo Rokisha z Fundacji Ethereum na ETHBoulder, wyjaśniająca zarządzanie głównym protokołem Ethereum, sposób koordynacji twardych rozwidleń, powszechne nieporozumienia dotyczące tego, kto kontroluje Ethereum, oraz jak uczestniczyć w procesie zarządzania.

Ten transkrypt jest dostępną kopią oryginalnego transkryptu wideo (opens in a new tab) opublikowanego przez EthBoulder. Został on lekko zredagowany w celu poprawy czytelności.

Wprowadzenie (0:12)

Dziękuję całej szóstce moich przyjaciół, którzy się pojawili. W porządku. Opowiem wam dzisiaj o zarządzaniu głównym protokołem Ethereum. Nazywam się Nixo. Kieruję zespołem wsparcia protokołu w EF (Fundacji Ethereum). Wśród wszystkich naszych zadań, jednym z nich jest uczynienie procesu zarządzania jaśniejszym i łatwiejszym do nawigowania dla wszystkich innych, którzy w nim uczestniczą, ponieważ Ethereum to znacznie więcej niż tylko jego główni deweloperzy (core developers).

Oto plan prezentacji. Porozmawiamy o tym, czym jest zarządzanie głównym protokołem. Omówimy nieporozumienia i to, jak obecnie funkcjonuje zarządzanie Ethereum. Zastanowimy się, jak wypada ono na tle innych zdecentralizowanych systemów zarządzania, dlaczego twórcy (builders) powinni się tym interesować oraz jakie są praktyczne ścieżki uczestnictwa.

Czym więc jest zarządzanie głównym protokołem? Prowadzę węzeł. Oznacza to, że mam sprzęt, komputer w domu, na którym uruchamiam oprogramowanie Ethereum. Kiedy konfigurowałem to oprogramowanie Ethereum, musiałem wybrać klientów, którzy będą je obsługiwać. Ethereum jest dość unikalne, ponieważ posiada wielu klientów w celu zapewnienia różnorodności klientów. Chodzi o to, że jeśli jeden klient przestanie działać, jeśli w kliencie pojawi się błąd, cała sieć nie padnie. Istnieją inne blockchainy, które mają innych klientów. Jednak Ethereum jest jedynym, który jest skonfigurowany w sposób faktycznie chroniący nas przed błędami. Jeśli spojrzysz na przykład na Solanę, Solana ma innego klienta, chyba nazywa się GTO, ale ma tylko 20–21% adopcji. Więc jeśli główny klient przestanie działać, łańcuch również przestaje działać. Widzieliśmy już, jak inne sieci padały. I właśnie dlatego Ethereum jest najbardziej odpornym i bezpiecznym blockchainem.

Pojawia się więc pytanie, jak wprowadzać zmiany w Ethereum, gdy trzeba koordynować działania z tak wieloma różnymi klientami. Najpierw odróżnimy twarde rozwidlenie od miękkiego rozwidlenia. Miękkie rozwidlenie nie wymaga takiej koordynacji jak twarde rozwidlenie. Ethereum działa głównie w oparciu o twarde rozwidlenia. Twarde rozwidlenie polega w zasadzie na tym, że wszyscy klienci budują nową wersję Ethereum i decydują się na uruchomienie tej nowej wersji w z góry określonym czasie. To wciąż Ethereum, ale ma nowe funkcje. Ma inne funkcje. A wszyscy operatorzy węzłów, tacy jak ja, którzy prowadzą węzły w domu, lub profesjonalni operatorzy, muszą zaakceptować tę nową wersję Ethereum. Muszą zaktualizować swój węzeł, aby zawierał to nowe oprogramowanie.

Jak więc decydują, jakie funkcje znajdą się w tych twardych rozwidleniach? Muszą uzgodnić priorytety, aby przydzielić swój czas i zasoby, ponieważ mają ograniczony czas i zasoby do dyspozycji. Priorytetowo traktują takie rzeczy jak luki w zabezpieczeniach lub łatki bezpieczeństwa, kwestie takie jak UX (doświadczenie użytkownika) — jeśli istnieje inny blockchain, który z nami konkuruje, musimy stać się konkurencyjni wobec tych innych blockchainów. Jedną z rzeczy, na które zwracają uwagę, jest to, że każda wprowadzana funkcja musi być kompatybilna w przód z potencjalnymi nadchodzącymi elementami mapy drogowej.

W zeszłym roku wydarzyła się naprawdę kontrowersyjna rzecz. Być może o tym słyszeliście. Nazywało się to EOF. To skrót od EVM Object Format. Był to zestaw funkcji, który miał wejść do twardego rozwidlenia Fusaka — Pectra, Fusaka, chyba obu — ale został podzielony. Jednym z wielu powodów, dla których został wyrzucony z tego rozwidlenia, było to, że Vitalik opublikował post o potencjalnym przyjęciu przez Ethereum architektury RISC-V. Wiele osób, które to czytały, pomyślało: okej, jeśli przyjmiemy RISC-V, funkcje, na które patrzymy w EOF, są natywne dla RISC-V. Więc po co mielibyśmy dodawać tę złożoność do protokołu? Dlaczego mielibyśmy przeznaczać na to wszystkie zasoby deweloperów klientów? Byłoby to bezcelowe, gdybyśmy ostatecznie przeszli na RISC-V.

To była kropla, która przelała czarę goryczy w przypadku EOF i ostatecznie zostało to wyrzucone z rozwidlenia. Kolejną rzeczą, którą muszą wziąć pod uwagę, jest to, że musi to być napisane i rygorystycznie przetestowane w sześciu różnych językach, ponieważ ci klienci są napisani w sześciu różnych językach. To naprawdę duża matryca testowa, z którą muszą pracować. Z tego powodu każdy najmniejszy wybór projektowy staje się przedmiotem debaty, bez żadnego autorytetu, który mógłby rozwiązywać spory. Pojawia się więc pytanie, kto decyduje — co jest sednem zarządzania.

Nieporozumienia (5:23)

To prowadzi nas do nieporozumień i zajmiemy się niektórymi z nich. Jednym z nich jest to, że Vitalik decyduje o tym, co wchodzi do protokołu Ethereum. Rozszerzeniem tego jest to, że Fundacja Ethereum kontroluje wszystko. Trzecim jest to, że to wszystko zakulisowe układy — wtajemniczeni, weterani (OGs) podejmujący te decyzje.

Więc pierwsze: Vitalik decyduje. Wybrałem tylko podzbiór wstrzymanych propozycji EIP (Ethereum Improvement Proposals) autorstwa Vitalika. Oznacza to, że Vitalik usiadł, napisał propozycję i powiedział: chcę, aby te rzeczy weszły do Ethereum, a nikt się nie zgodził — te rzeczy po prostu tam leżą. Nie był w stanie wprowadzić ich do protokołu. Więc nie wszystko, co proponuje, jest automatycznie uwzględniane.

Rozszerzeniem tego jest to, że Fundacja Ethereum kontroluje wszystko. Wybiorę konkretny przykład sytuacji, która moim zdaniem temu przeczy. W 2024 roku dużo mówiło się o limicie gazu. Powodem tego jest to, że w 2022 roku podczas The Merge podnieśliśmy limit gazu do 30 milionów. To maksymalna ilość obliczeń dozwolona w bloku. Potem przez jakiś czas tego nie ruszaliśmy, ponieważ nie było to tak naprawdę wąskim gardłem, o którym ludzie mówiliby: „Dlatego nie przechodzę na Ethereum” lub „To ogranicza mój obecny przypadek użycia Ethereum”.

Pod koniec 2023 i na początku 2024 roku pojawiła się narracja, że nadchodzi Solana. Że zostawi Ethereum w tyle. Ludzie zastanawiali się więc, co Ethereum może zrobić, aby przyspieszyć. Jedną z rzeczy było: podkręćmy tę metrykę gazu. W tamtym czasie EF i deweloperzy klientów mówili coś w stylu: „Mamy inne rzeczy na głowie. Ale dzięki”. Jednak te dwie osoby, Eric Connor i Mariano Conti, przyszły i powiedziały: „Nie, podnosimy limit gazu”. Limit gazu to parametr kontrolowany przez walidatorów. Mogli więc po prostu zacząć rozmawiać z walidatorami, profesjonalnymi operatorami i powiedzieć: „Hej, podnieście swój limit gazu”.

W pewnym momencie adopcja była na tyle duża, że EF i klienci stwierdzili: „Och, musimy zwrócić na to uwagę. Musimy upewnić się, że to, co robią, jest bezpieczne i że wartość, do której ostatecznie to podniosą, będzie bezpieczna dla sieci”. Musieli więc ponownie przydzielić swoje zasoby. Nethermind wymyślił ten framework testowy. EF wykonała mnóstwo pracy w Berlinie. Wszyscy deweloperzy klientów przeprowadzali testy wydajnościowe. Podoba mi się to, ponieważ zmusiło to EF do podjęcia decyzji o tym, co jest priorytetem.

Podoba mi się też ten głupi tweet, którego zrzut ekranu tu zamieściłem, ponieważ to jakiś przypadkowy portal informacyjny nazywający Erica Connora i Mariano Contiego głównymi deweloperami (core devs). Oni nie są głównymi deweloperami. Eric Connor był stakerem i członkiem społeczności. Mariano Conti był byłym deweloperem aplikacji MakerDAO. Ale zostali nazwani głównymi deweloperami, ponieważ rozwój Ethereum jest naprawdę poza światem tego, jak działa tradycyjne oprogramowanie, więc zobaczyli, że modyfikowany jest główny parametr i pomyśleli: „Och, to muszą być główni deweloperzy”. Nie byli. To tylko przykład członków społeczności, którzy przychodzą i mówią, że chcą zobaczyć tę zmianę, i doprowadzają do jej realizacji.

To wszystko zakulisowe układy, wtajemniczeni, weterani — trochę bardziej rozumiem, dlaczego jest to nieporozumienie, ponieważ w zasadzie przychodzisz na te spotkania dotyczące zarządzania, a na nich jest stu ludzi. Wydaje się, że wszyscy czują się bardzo swobodnie z tym, co się dzieje. Ty jesteś zagubiony. Nie masz pojęcia, jak podejmowane są te decyzje. Zastanawiasz się: „Czy to już moja kolej, żeby coś powiedzieć?”. I wydaje się, że ludzie słuchają tych samych 10 osób, aby podjąć te decyzje.

Merytokracja i statystyki uczestnictwa (10:18)

Ale prawda jest taka, że rozwój Ethereum jest w większym stopniu merytokracją, niż kiedykolwiek widziałem w większości projektów programistycznych. Wszyscy ci ludzie na tym zrzucie ekranu — to jeden z trzech z tego przypadkowego spotkania ACD (All Core Devs), z którego postanowiłem zrobić zrzut ekranu — nikt z tych ludzi nie został tu mianowany. Wszyscy to po prostu ludzie, którzy się pojawili. To deweloperzy, którzy spędzili dużo czasu z tym protokołem. To oni zostali uznani przez innych za utalentowanych deweloperów w tej przestrzeni, konsekwentnie podejmujących dobre decyzje, i nikt z nich nie został wyznaczony, by tu być.

Dołączyłem do EF zaledwie nieco ponad rok temu. Zebrałem te statystyki. Sięgają one tylko do marca 2025 roku. Czyli mniej niż rok. Średnia liczba uczestników All Core Dev — to są spotkania dotyczące zarządzania — wynosi 98. Średnio w tych spotkaniach bierze udział 98 osób. Maksymalna liczba uczestników na jednym spotkaniu od tego czasu wyniosła 153. Myślę, że to był dzień, w którym decydowaliśmy o dacie uruchomienia Pectra w sieci głównej. Całkowita liczba unikalnych uczestników to 567 tylko w ostatnim roku. Bardzo podoba mi się ta metryka, ponieważ pokazuje, że to nie jest tych samych 100 osób, które za każdym razem uczestniczą w tych spotkaniach. Ci deweloperzy aplikacji, badacze, ktoś słyszy o jakiejś omawiananej funkcji, pojawia się, aby wyrazić swój sprzeciw lub poparcie dla niej, a potem nie przychodzi na kolejne spotkanie.

Jak działa proces zarządzania (11:52)

To trochę suchy slajd, ale myślę, że ważne jest, aby go omówić — tak obecnie działa zarządzanie Ethereum. Kiedy omawiane jest jedno z tych rozwidleń, pierwszą rzeczą, która się dzieje, jest to, że ludzie w wyznaczonym oknie czasowym mogą zgłaszać swoje główne propozycje (headliner proposals). Główna propozycja to najważniejsza funkcja, wokół której chcemy zgromadzić ludzi dla tego rozwidlenia. Może to być członek społeczności, badacz, główny deweloper — tak naprawdę każdy, kto zgłasza jedną z tych głównych propozycji. Następnie okno się zamyka i na spotkaniach dotyczących zarządzania dyskutujemy, która z nich ma sens. Ludzie przedstawiają swoje argumenty, dyskutują i osiągany jest konsensus co do tego, którą z nich powinniśmy wybrać dla nadchodzącego rozwidlenia.

Następnie wybierają pomniejsze funkcje. Czyli mniejsze rzeczy, które nie muszą być głównymi funkcjami napędzającymi rozwidlenie. Przez cały ten czas mamy sieci deweloperskie (devnets) specyficzne dla danej funkcji. Sieć deweloperska jest jak sieć testowa — prywatna sieć testowa dla deweloperów do testowania tych funkcji i upewnienia się, że faktycznie działają one na Ethereum. W pewnym momencie następuje zamrożenie funkcji (feature freeze). Omówiliśmy więc główne funkcje, omówiliśmy pomniejsze funkcje, uruchomiliśmy te specyficzne dla funkcji sieci deweloperskie, które zazwyczaj są głównymi elementami rozwidlenia. I to jest zamrożenie funkcji z gwiazdką, ponieważ w tym momencie zdecydowaliśmy, że nie dodamy już żadnych nowych funkcji do tego rozwidlenia. Uruchomimy wszystkie funkcje razem, upewnimy się, że wszystko jest w porządku, że nic się nie zepsuje. Ale jeśli coś zacznie spowalniać proces, jeśli rozwidlenie jest opóźnione, jeśli jest zbyt złożone, rzeczy wciąż mogą zostać wyrzucone na tym etapie.

Po kilku sieciach deweloperskich — mogą to być dwie, może być ich 10 — wszyscy klienci w pewnym momencie decydują, że jest to stabilne. Ufamy temu, co się teraz dzieje. Jesteśmy w dobrym miejscu. Zacznijmy myśleć o wypuszczeniu tego do sieci głównej Ethereum. Wypuszczają wersje klientów, a następnie następuje 30-dniowy okres, w którym zespół ds. bezpieczeństwa EF ogłasza program nagród za znalezienie błędów (bug bounty). Zlecają audyty bezpieczeństwa. A pod koniec tego 30-dniowego okresu uruchamiamy rozwidlenie w sieciach testowych. To sieci testowe, o których mogliście słyszeć — jak Holesky. To tam deweloperzy aplikacji mogą testować swoje rzeczy, zanim rozwidlenie wejdzie w życie. Zazwyczaj trwają one minimum 14 dni każda, tylko po to, aby upewnić się, że wszystko jest w porządku. Nie spodziewamy się żadnych większych problemów, ponieważ przeszło to wcześniej przez specyficzne dla funkcji sieci deweloperskie i ogólne sieci deweloperskie, ale historycznie zdarzało się, że psuło to niektóre z tych sieci testowych. Jest to więc swego rodzaju ostatni dzwonek na znalezienie i wyeliminowanie wszystkich tych błędów.

A kiedy niewymagająca pozwoleń sieć testowa jest stabilna, wybierana jest data dla sieci głównej. Następnie jest 30-dniowy bufor. Ten 30-dniowy bufor istnieje, ponieważ warstwy drugie (L2) i protokoły prosiły o to, aby przygotować się na rozwidlenie. To minimum 30 dni, a potem następuje rozwidlenie.

Struktura spotkań i koordynacja (15:01)

Przez cały ten czas odbywają się główne serie spotkań. Są to publiczne spotkania transmitowane na żywo na YouTube. Główne z nich to ACDE i ACDC. E oznacza warstwę wykonawczą (execution layer) — to rzeczy takie jak transakcje, wdrażanie inteligentnych kontraktów, zarządzanie mempoolem. ACDC to warstwa konsensusu (consensus layer) — czyli sprawy walidatorów, takie jak zarządzanie walidatorami, cięcie (slashing). Odbywają się one na przemian w czwartki. W każdy czwartek jest spotkanie ACD, jedno z nich to ACDE, a następne to ACDC, i tak na zmianę.

Spotkania ACDE i ACDC skupiają się na rozwidleniu, które obecnie tworzymy, oraz na rozwidleniach, które planujemy na przyszłość. Spotkania ACDT są bardziej szczegółowe i wchodzą w detale. To klienci rozmawiający o błędach, których nie mogą obejść, lub szczegółach implementacji, które należy rozwiązać w związku z rozwidleniem, nad którym obecnie pracują. Obecnie następnym rozwidleniem jest Glamsterdam. Te spotkania ACDT są więc zdominowane przez rozmowy o ePBS i listach dostępu na poziomie bloku, które są rzeczami wchodzącymi do Glamsterdam. Są to wysoce techniczne spotkania.

Są też spotkania robocze (breakout calls). Spotkania robocze to członkowie społeczności, badacze, deweloperzy mówiący: „Hej, mam funkcję, którą chcę wprowadzić do Ethereum za dwa rozwidlenia”. Organizują więc te cotygodniowe, comiesięczne lub odbywające się co dwa miesiące spotkania, na których omawiają szczegóły implementacji, zmieniają i iterują specyfikację oraz ogólnie odpowiadają na wszystkie pytania, które mają ludzie, wszystkie znane niewiadome, aby upewnić się, że jest to w najlepszym możliwym miejscu, aby zostać włączonym do rozwidlenia za dwa rozwidlenia. Mogą one być zaplanowane w dowolnym momencie, o którym zdecyduje facylitator.

Ewoluujący proces (15:29)

Jedną rzeczą, którą chcę wszystkim uświadomić, jest to, że ten proces wcale nie jest statyczny. Proces, który właśnie wam opisałem, działa od niespełna roku. Ethereum działa od 10 lat. Ale to stale się zmienia, a powodem, dla którego stale się zmienia, jest to, że nikt nie rządzi. Ten proces w pewnym sensie ewoluuje, aby znaleźć najbardziej efektywny sposób działania. Mówię efektywny, ale reputacja zarządzania Ethereum jest taka, że jest ono naprawdę w stagnacji, trudno coś przeforsować, jest mylące — a to dlatego, że kiedy masz od 100 do 500 osób podejmujących decyzje, szczerze mówiąc, jestem pod wrażeniem, że to w ogóle działa.

Tim opublikował post w kwietniu 2025 roku zatytułowany „Reconfiguring All Core Devs”, który ostatecznie stał się propozycją tego, jak rzeczy działają obecnie. Powodem tego jest to, że wcześniej mieliśmy spójną narrację na temat tego, na czym powinniśmy się skupić w Ethereum. Było The Merge, które było ogromnym przedsięwzięciem. Wszyscy byli bardzo podekscytowani. Większość ludzi była bardzo podekscytowana. Górnicy nie byli. A po The Merge pojawiły się wypłaty. Nie chcieliśmy, aby ludzie mieli swoje ETH zablokowane w kontrakcie i żeby pojawił się FUD, że nigdy nie odzyskają z tego swojego ETH. Musieliśmy więc dostarczyć to tak szybko, jak to możliwe. Potem było proto-danksharding, a potem nadeszła Pectra, a Pectra była swego rodzaju amalgamatem różnych, niepowiązanych ze sobą EIP i tak naprawdę nie miała spójnej narracji. Stała się tak duża, ponieważ ludzie po prostu wrzucali tam rzeczy z powodu braku spójności, że musiała zostać podzielona na dwa różne rozwidlenia, ponieważ zespoły testujące stwierdziły: „Zakres jest o wiele za duży. Nie możemy tego wszystkiego przetestować”.

Impulsem Tima do zrobienia tego było: okej, musimy wymyślić sposób, aby te rozwidlenia były jak najbardziej skoncentrowane i spójne. Główna propozycja (headliner) była swego rodzaju odpowiedzią na to. Chodziło o to, aby dostarczać aktualizacje w sposób, który priorytetowo traktował poczucie, że wszyscy wiedzą, o co chodzi w rozwidleniu, aby nie musieli wrzucać 25 różnych EIP.

Drugi zrzut ekranu na górze to Tim proponujący definicje etapów włączania tych EIP. Chcę przez to powiedzieć, że czasami słyszy się, jak ludzie mówią, że ten proces jest zbyt biurokratyczny. Ale tak naprawdę dzieje się to, że ludzie wchodzą w ten proces zarządzania i pytają: „Jak wprowadzić EIP?”, a ludzie, którzy są tam od 10 lat, odpowiadają: „Po prostu to robisz”. A ludzie na to: „To jest okropne”. Więc to, co robią te rzeczy, to opisują, co się dzieje, aby ułatwić osobom z zewnątrz uczestnictwo w tym procesie, ponieważ jeśli po prostu tu przychodzisz i mówisz: „Mam jedno EIP, nie obchodzi mnie zarządzanie Ethereum, chcę tylko, żeby to jedno EIP weszło” — chcesz rubryki, chcesz listy kontrolnej, chcesz bardzo jasnego przewodnika krok po kroku, jak wprowadzić to EIP. Większość z tych rzeczy dotyczy więc bardziej opisywania, jak działa proces, niż tworzenia biurokratycznych zasad, których ludzie muszą przestrzegać, aby utrudnić wprowadzanie EIP.

Trzecia rzecz to commity w czasie na Forkcast. Forkcast to produkt mojego zespołu, autorstwa Wolframa Marka, faceta z mojego zespołu, który stworzył to w połowie zeszłego roku, kiedy powstał mój zespół w obecnej formie. Stało się to tak kanonicznym zasobem dla ludzi do interakcji z rozwidleniem, aby zobaczyć, co wchodzi do rozwidlenia i jak to na nich wpływa. Wszystkie te rzeczy mają mniej niż dwa lata. Chcę tylko powiedzieć, że ten proces bardzo się zmienia. Wcale nie jest statyczny. To nie jest jakaś zamrożona biurokracja, do której trudno się dostać.

Porównywalne systemy zarządzania (20:21)

Chciałem tylko szybko poruszyć temat najbardziej podobnych zdecentralizowanych systemów zarządzania, jakie widzę w stosunku do zarządzania Ethereum. Chcę przez to powiedzieć, że jest to zrównoważone — mimo że to niesamowite, że od 100 do 500 osób może podejmować decyzje, jest to zrównoważone w prawdziwym świecie. Widzimy przykłady, że to działa.

IETF to Internet Engineering Task Force. To prowadzona przez wolontariuszy organizacja normalizacyjna, która stworzyła TCP/IP, HTTP. Jest to organizacja najbardziej odpowiedzialna za to, że mamy dziś wolny internet. Jądro Linuxa — to rdzeń systemu operacyjnego Linux. To oprogramowanie open-source, które napędza serwery internetowe, telefony z Androidem, superkomputery. Różnica polega na tym, że mają tam swego rodzaju model łaskawego dyktatora z Linusem Torvaldsem. Ale nawet wtedy mają ponad 17 000 współtwórców, co jest oszałamiające.

Rzeczy, do których to nie jest podobne: inne blockchainy, które mają głosowanie tokenami onchain. Ethereum celowo unika jakiegokolwiek mechanizmu głosowania, ponieważ moim zdaniem prowadzi to do możliwości przejęcia kontroli i w pewnym sensie pozbywa się zachęty do uczynienia rzeczy merytokracją, w której ludzie po prostu ufają tym, którzy piszą najlepszy kod. Są też warstwy drugie (L2). Mają portfele z wieloma podpisami (multi-sig). Mają rady bezpieczeństwa. Są to bardziej mianowane stanowiska, które podejmują te decyzje. I to ma swoje kompromisy. Jest bardziej scentralizowane. Chociaż działa szybciej.

Dlaczego twórcy powinni się tym interesować (22:38)

Dlaczego więc twórcy (builders) interesują się zarządzaniem? Ponieważ twórcy to dosłownie ci, dla których stworzono Ethereum. Ethereum nie zostało stworzone dla głównych deweloperów. Nie zostało stworzone dla walidatorów. Czasami ci ludzie się w tym gubią. Główni deweloperzy i walidatorzy Ethereum służą Ethereum, które służy twórcom i użytkownikom.

Każdy miał taki moment ze sztuczną inteligencją (AI), kiedy wchodzisz zbyt głęboko w szczegóły, a ona próbuje naprawić tę małą rzecz i nie potrafi spojrzeć z szerszej perspektywy na cały cel projektu. Główni deweloperzy mogą być tacy sami, gdy próbują udoskonalić proces głównego rozwoju. W takim przypadku bardzo ważne jest, aby twórcy wkroczyli, ponieważ główny rozwój jest tak pochłaniający, że przez większość czasu nie budują oni również na Ethereum. Są bardzo zaangażowani w główny rozwój. Zajmuje to cały ich czas. Dlatego twórcy aplikacji naprawdę muszą podjąć wysiłek, aby przyjść i powiedzieć: „Hej, potrzebujemy tego. To jest kluczowe dla Ethereum”. Tylko po to, aby upewnić się, że ta perspektywa jest obecna i że nie zostają zaszufladkowani do pracy tylko dla głównych deweloperów.

Jak uczestniczyć (24:40)

Jak więc uczestniczyć lub wprowadzić swoją funkcję? To dość ogólna rada, ale myślę, że jest najlepsza. Głośno mów o swoich problemach. Wejdź na Twittera, pisz posty na blogu, identyfikuj rozwiązania swoich problemów. Spekuluj na temat rzeczy, które mogłyby ci pomóc. Jeśli znajdziesz inne osoby, które mają te same problemy, zazwyczaj możesz znaleźć EIP, które istnieje, aby rozwiązać ten problem, lub poprosić kogoś o pomoc w napisaniu EIP, które to zrobi.

Jedną z rzeczy, które lubię w oprogramowaniu open-source, jest to, że ogólnie dobrze dokapitalizowane firmy przeznaczają czas i zasoby swoich deweloperów na utrzymanie narzędzi open-source, z których korzystają. Kończy się to tym, że wiele różnych firm współpracuje przy utrzymaniu tej rzeczy i tak samo może to działać w Ethereum. Jeśli więc zidentyfikowałeś jakiś problem, możesz znaleźć dewelopera Base, który ma podobny problem, a Base jest dobrze dokapitalizowaną organizacją, więc prawdopodobnie byliby skłonni przeznaczyć trochę zasobów na dostarczenie funkcji lub przeprowadzenie jej przez twarde rozwidlenie Ethereum.

Zostawię wam tylko kilka zasobów. Forkcast.org — to miejsce, do którego możesz się udać i zobaczyć, co wchodzi do rozwidlenia, jak to wpływa na poszczególnych interesariuszy. Jeśli więc jesteś deweloperem aplikacji, jest tam sekcja dla deweloperów aplikacji. Jeśli jesteś deweloperem portfela, deweloperem klienta warstwy konsensusu, są tam sekcje o tym, jak to wszystko na ciebie wpływa. YouTube to miejsce, gdzie przesyłane są wszystkie filmy ze spotkań. Są one również osadzone na stronie forkcast.org/calls, gdzie znajdują się podsumowania, przypisania mówców, dzięki czemu łatwiej jest nawigować po tych spotkaniach. Katalog EIP, forum Ethereum Magicians, gdzie możesz porozmawiać z innymi ludźmi o potencjalnych rozwiązaniach lub EIP, które chcesz napisać. A już wkrótce mój zespół będzie miał stronę wsparcia protokołu. Wygląda niesamowicie. Nie jest jeszcze gotowa do udostępnienia. Jest tam również mój e-mail — nixo@ethereum.org (opens email client). To wszystko.