Cena Layer3

Mając na uwadze następujące kwestie: Wyobraźmy sobie, że mamy OP_CAT i że rzeczywiście dało nam to introspekcję, STARKi + zdolność przenoszenia stanów (do budowania rollupów, walidacji itp.), a nawet inne kody operacyjne, które rozwiązują to jeszcze bardziej zgrabnie (wybierz OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit="" arithmetic="" opcodes="" here="">) Jak wyglądałaby idealna konstrukcja L2 dla Bitcoina? Czego nie chcemy robić: powtarzać strategii Ethereum – 200 rywalizujących ze sobą zespołów budujących różne L2, słaba łączność/komponowalność rywalizująca o tych samych użytkowników, co *DO* chcemy zrobić? Jakie lekcje możemy wyciągnąć z Ethereum? Pamiętaj, że nie możemy (ani nie chcemy) tworzyć agregacji na podstawie. L1 jest na to zbyt wolny, a my nie chcemy warstwy podstawowej MEV tego rodzaju. Pamiętaj też, że chcemy, aby: - System transakcyjny o wysokim TPS (Lightning w zasadzie bez kanałów) - Niektórzy będą chcieli większej ekspresji (w przypadku pożyczek stablecoin bez zaufania, swapów AMM, skarbców, planów dziedziczenia, produktów lewarowanych) Jeśli te dwa typy systemów istnieją w tej samej warstwie wykonawczej, czy też najlepiej jest oddzielić płatności od aplikacji z różnymi kolejkami sekwencjonowania (skłaniam się ku temu) — może chcemy pójść w kierunku Celestii, aby zrobić jeden zkVM L2, a wszystkie inne systemy jako L3, oddzielne kolejki, ale agregację przez L2. Robienie prawdziwych rollupów dla czegokolwiek na dużą skalę jest w zasadzie wykluczone z wizji gry końcowej, biorąc pod uwagę niską przepustowość L1 i potrzeby DA (a dodawanie blobów wydaje się bardzo mało prawdopodobne), więc najprawdopodobniej uruchomilibyśmy jakiś rodzaj walidacji + zewnętrzna warstwa DA, zk-plasma lub architektury oparte na walidacji po stronie klienta, takie jak Miden. Powinniśmy również zbadać, czy chcemy czystych systemów ZK, czy hybrydowych ("optymistyczny ZK", patrz Paliwo), aby jeszcze bardziej zmaksymalizować przepustowość. Jednym ze sposobów jest pozwolenie wolnemu rynkowi na zwycięstwo i po prostu zobaczenie, co się stanie, ale to właśnie zrobiło Ethereum. Nawet jeśli wyciągniemy wnioski z siebie, a zespoły będą starały się koordynować działania wokół pojedynczych rozwiązań agregacyjnych od samego początku, nie ma żadnej gwarancji, że to zadziała. Nie mamy również żadnej możliwości zapisania żadnej konkretnej warstwy wykonawczej za pośrednictwem L1. Mimo to jest dla mnie jasne, że STARKi stanowią najlepszą ścieżkę dla wszystkich poniższych: - Płatności oparte na minimalnym zaufaniu (bez wymagań dotyczących kanałów, routingu i płynności) - Wyrazistość (dla tych, którzy tego chcą) - Prywatność (pełne maszyny wirtualne ZK-privacy) - Osiągnięcie wszystkich powyższych celów bez wprowadzania żadnych egzotycznych założeń kryptograficznych, zaufanych konfiguracji itp. Możesz zapytać o ostateczność ze względu na opóźnienia L1, ale imo można to całkiem wyraźnie rozwiązać w zadowalającym stopniu za pomocą połączonych sekwencerów dla szybkich pre-konfografii. Mamy więc wszystkie narzędzia, co robimy, aby osiągnąć jak najlepszy wynik? Podczas gdy BTC powinien być oczywiście walutą dla wszystkich tych systemów (i płacić za opłaty/gaz), pozostaje ostatnie (a może pierwsze) pytanie o to, jak to wszystko osiągnąć bez wprowadzania tokena L2 w większości kontrolowanego przez Fundację o zbyt dużej kontroli. Myślę, że system oparty tylko na płatnościach może działać dobrze bez tokena zarządzania (tylko z centralnym sekwencjonowaniem + jednostronnymi wyjściami przeciwko cenzurze), ale wątpię w to w przypadku czegokolwiek wyrazistego. Podczas gdy większość fundacji/DAO ma za cel decentralizację, oddanie tak dużej władzy w ręce scentralizowanej organizacji, nawet w fazie bootstrappingu, wydaje mi się nieoptymalne, jeśli chcemy od samego początku jakiegoś zbiorowego podejścia w celu złagodzenia ryzyka fragmentacji. Byłoby wspaniale usłyszeć, co inni ludzie myślą od osób z doświadczeniem z innych ekosystemów, takich jak Ethereum, Celestia, Polygon, Cosmos, a także ciekawi, jak na te pytania myślą obecne zespoły L2 pracujące nad Bitcoinem (np. Alpen, Chainway, Starkware). Nie krępuj się dołączyć w komentarzach!</insert>

Mając na uwadze następujące kwestie: Wyobraźmy sobie, że mamy OP_CAT i że rzeczywiście dało nam to introspekcję, STARKi + zdolność przenoszenia stanów (do budowania rollupów, walidacji itp.), a nawet inne kody operacyjne, które rozwiązują to jeszcze bardziej zgrabnie (wybierz OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit="" arithmetic="" opcodes="" here="">) Jak wyglądałaby idealna konstrukcja L2 dla Bitcoina? Czego nie chcemy robić: powtarzać strategii Ethereum – 200 rywalizujących ze sobą zespołów budujących różne L2, słaba łączność/komponowalność rywalizująca o tych samych użytkowników, co *DO* chcemy zrobić? Jakie lekcje możemy wyciągnąć z Ethereum? Pamiętaj, że nie możemy (ani nie chcemy) tworzyć agregacji na podstawie. L1 jest na to zbyt wolny, a my nie chcemy warstwy podstawowej MEV tego rodzaju. Pamiętaj też, że chcemy, aby: - System transakcyjny o wysokim TPS (Lightning w zasadzie bez kanałów) - Niektórzy będą chcieli większej ekspresji (w przypadku pożyczek stablecoin bez zaufania, swapów AMM, skarbców, planów dziedziczenia, produktów lewarowanych) Jeśli te dwa typy systemów istnieją w tej samej warstwie wykonawczej, czy też najlepiej jest oddzielić płatności od aplikacji z różnymi kolejkami sekwencjonowania (skłaniam się ku temu) — może chcemy pójść w kierunku Celestii, aby zrobić jeden zkVM L2, a wszystkie inne systemy jako L3, oddzielne kolejki, ale agregację przez L2. Robienie prawdziwych rollupów dla czegokolwiek na dużą skalę jest w zasadzie wykluczone z wizji gry końcowej, biorąc pod uwagę niską przepustowość L1 i potrzeby DA (a dodawanie blobów wydaje się bardzo mało prawdopodobne), więc najprawdopodobniej uruchomilibyśmy jakiś rodzaj walidacji + zewnętrzna warstwa DA, zk-plasma lub architektury oparte na walidacji po stronie klienta, takie jak Miden. Powinniśmy również zbadać, czy chcemy czystych systemów ZK, czy hybrydowych ("optymistyczny ZK", patrz Paliwo), aby jeszcze bardziej zmaksymalizować przepustowość. Jednym ze sposobów jest pozwolenie wolnemu rynkowi na zwycięstwo i po prostu zobaczenie, co się stanie, ale to właśnie zrobiło Ethereum. Nawet jeśli wyciągniemy wnioski z siebie, a zespoły będą starały się koordynować działania wokół pojedynczych rozwiązań agregacyjnych od samego początku, nie ma żadnej gwarancji, że to zadziała. Nie mamy również żadnej możliwości zapisania żadnej konkretnej warstwy wykonawczej za pośrednictwem L1. Mimo to jest dla mnie jasne, że STARKi stanowią najlepszą ścieżkę dla wszystkich poniższych: - Płatności oparte na minimalnym zaufaniu (bez wymagań dotyczących kanałów, routingu i płynności) - Wyrazistość (dla tych, którzy tego chcą) - Prywatność (pełne maszyny wirtualne ZK-privacy) - Osiągnięcie wszystkich powyższych celów bez wprowadzania żadnych egzotycznych założeń kryptograficznych, zaufanych konfiguracji itp. Możesz zapytać o ostateczność ze względu na opóźnienia L1, ale imo można to całkiem wyraźnie rozwiązać w zadowalającym stopniu za pomocą połączonych sekwencerów dla szybkich pre-konfografii. Mamy więc wszystkie narzędzia, co robimy, aby osiągnąć jak najlepszy wynik? Podczas gdy BTC powinien być oczywiście walutą dla wszystkich tych systemów (i płacić za opłaty/gaz), pozostaje ostatnie (a może pierwsze) pytanie o to, jak to wszystko osiągnąć bez wprowadzania tokena L2 w większości kontrolowanego przez Fundację o zbyt dużej kontroli. Myślę, że system oparty tylko na płatnościach może działać dobrze bez tokena zarządzania (tylko z centralnym sekwencjonowaniem + jednostronnymi wyjściami przeciwko cenzurze), ale wątpię w to w przypadku czegokolwiek wyrazistego. Podczas gdy większość fundacji/DAO ma za cel decentralizację, oddanie tak dużej władzy w ręce scentralizowanej organizacji, nawet w fazie bootstrappingu, wydaje mi się nieoptymalne, jeśli chcemy od samego początku jakiegoś zbiorowego podejścia w celu złagodzenia ryzyka fragmentacji. Byłoby wspaniale usłyszeć, co inni ludzie myślą od osób z doświadczeniem z innych ekosystemów, takich jak Ethereum, Celestia, Polygon, Cosmos, a także ciekawi, jak na te pytania myślą obecne zespoły L2 pracujące nad Bitcoinem (np. Alpen, Chainway, Starkware). Nie krępuj się dołączyć w komentarzach!</insert>