Cena Layer3

Přemýšlejte o následujícím: Představme si, že jsme měli OP_CAT a že nám to skutečně dalo introspekci, STARKy + schopnost nést stav (vytvářet rollupy, validia atd.), nebo dokonce jiné operační kódy, které to řeší ještě úhledněji (vyberte si OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit="" arithmetic="" opcodes="" here="">) Jak by vypadala ideální konstrukce L2 pro Bitcoin? Co nechceme dělat: opakovat scénář Etherea – 200 konkurenčních týmů budujících různé L2, špatná interkonektivita/skládatelnost a všichni soutěžící o stejné uživatele, co *DO* chceme udělat? Jaké ponaučení si můžeme z Etherea vzít? Mějte na paměti, že nemůžeme (ani nechceme) dělat kumulativní aktualizace. Na to je L1 příliš pomalý a my nechceme základní vrstvu MEV tohoto druhu. Také mějte na paměti, že chceme: - Transakční systém s vysokým TPS (v podstatě Lightning bez kanálů) - Někteří budou chtít větší expresivitu (pro půjčky stablecoin bez důvěry, swapy AMM, trezory, dědické plány, pákové produkty) Pokud by tyto dva typy systémů existovaly na stejné prováděcí vrstvě, nebo je nejlepší oddělit platby od aplikací s různými sekvenčními frontami (mám tendenci věřit, že ano) – možná bychom chtěli jít směrem Celestia-like a dělat jeden zkVM L2 a všechny ostatní systémy jako L3, oddělené fronty, ale agregaci přes L2. Dělat skutečné rollupy pro cokoli ve velkém měřítku je v podstatě mimo otázku pro vizi endgame vzhledem k nízké propustnosti L1 a potřebám DA (a přidávání blobů se zdá být velmi nepravděpodobné), takže bychom s největší pravděpodobností provozovali nějakou variantu validií + externí DA-vrstva, zk-plazma nebo architektury založené na ověřování na straně klienta, jako je Miden. Také bychom měli prozkoumat, zda chceme čisté ZK-systémy nebo hybridní proving ("optimistický ZK", viz Fuel for ref), abychom ještě více maximalizovali propustnost. Jedním ze způsobů je nechat volný trh vyhrát a počkat, co se stane, ale to je to, co Ethereum udělalo. I když si z toho vezmeme ponaučení a týmy se budou snažit koordinovat kolem jednotlivých agregačních řešení hned od začátku, neexistuje vůbec žádná záruka, že to bude fungovat. Také nemáme žádnou možnost zakotvit žádnou konkrétní vrstvu provádění prostřednictvím L1. Přesto je mi jasné, že STARK představují nejlepší cestu pro všechny následující: - Platby s minimalizací důvěry (bez kanálů, směrování nebo požadavků na likviditu) - Expresivita (pro ty, kteří ji chtějí) - Ochrana osobních údajů (plné virtuální počítače se ZK soukromí) - Dosažení všech výše uvedených cílů bez zavedení jakýchkoli exotických kryptografických předpokladů, důvěryhodných nastavení atd. Můžete se ptát na konečnost kvůli latenci L1, ale imo to lze docela jasně vyřešit do uspokojivé míry pomocí spojených sekvencerů pro rychlé předkonfekce. Takže máme všechny nástroje, co děláme pro to, abychom zajistili co nejlepší výsledek? Zatímco BTC by samozřejmě měl být měnou pro všechny tyto systémy (a platit za poplatky/plyn), je tu poslední (nebo možná první) otázka, jak toho všeho dosáhnout, aniž bychom zavedli L2 token z velké části kontrolovaný Nadací s příliš velkou kontrolou. Myslím, že systém pouze plateb může fungovat dobře bez tokenu správy (pouze s centrálním řazením + jednostrannými výstupy proti cenzuře), ale pochybuji o tom, že by to mělo něco výrazného. Zatímco většina nadací/DAO má za cíl decentralizaci, dát tolik moci do rukou centralizované organizace i ve fázi bootstrappingu se mi nezdá optimální, pokud chceme od samého začátku nějaký druh kolektivního přístupu, který zmírní rizika fragmentace. Bylo by skvělé slyšet, co si myslí ostatní lidé od lidí se zkušenostmi z jiných ekosystémů, jako je Ethereum, Celestia, Polygon, Cosmos, a také zvědaví, jak o těchto otázkách přemýšlejí současné L2 týmy pracující na Bitcoinu (např. Alpen, Chainway, Starkware). Neváhejte se ozvat v komentářích!</insert>

Přemýšlejte o následujícím: Představme si, že jsme měli OP_CAT a že nám to skutečně dalo introspekci, STARKy + schopnost nést stav (vytvářet rollupy, validia atd.), nebo dokonce jiné operační kódy, které to řeší ještě úhledněji (vyberte si OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit="" arithmetic="" opcodes="" here="">) Jak by vypadala ideální konstrukce L2 pro Bitcoin? Co nechceme dělat: opakovat scénář Etherea – 200 konkurenčních týmů budujících různé L2, špatná interkonektivita/skládatelnost a všichni soutěžící o stejné uživatele, co *DO* chceme udělat? Jaké ponaučení si můžeme z Etherea vzít? Mějte na paměti, že nemůžeme (ani nechceme) dělat kumulativní aktualizace. Na to je L1 příliš pomalý a my nechceme základní vrstvu MEV tohoto druhu. Také mějte na paměti, že chceme: - Transakční systém s vysokým TPS (v podstatě Lightning bez kanálů) - Někteří budou chtít větší expresivitu (pro půjčky stablecoin bez důvěry, swapy AMM, trezory, dědické plány, pákové produkty) Pokud by tyto dva typy systémů existovaly na stejné prováděcí vrstvě, nebo je nejlepší oddělit platby od aplikací s různými sekvenčními frontami (mám tendenci věřit, že ano) – možná bychom chtěli jít směrem Celestia-like a dělat jeden zkVM L2 a všechny ostatní systémy jako L3, oddělené fronty, ale agregaci přes L2. Dělat skutečné rollupy pro cokoli ve velkém měřítku je v podstatě mimo otázku pro vizi endgame vzhledem k nízké propustnosti L1 a potřebám DA (a přidávání blobů se zdá být velmi nepravděpodobné), takže bychom s největší pravděpodobností provozovali nějakou variantu validií + externí DA-vrstva, zk-plazma nebo architektury založené na ověřování na straně klienta, jako je Miden. Také bychom měli prozkoumat, zda chceme čisté ZK-systémy nebo hybridní proving ("optimistický ZK", viz Fuel for ref), abychom ještě více maximalizovali propustnost. Jedním ze způsobů je nechat volný trh vyhrát a počkat, co se stane, ale to je to, co Ethereum udělalo. I když si z toho vezmeme ponaučení a týmy se budou snažit koordinovat kolem jednotlivých agregačních řešení hned od začátku, neexistuje vůbec žádná záruka, že to bude fungovat. Také nemáme žádnou možnost zakotvit žádnou konkrétní vrstvu provádění prostřednictvím L1. Přesto je mi jasné, že STARK představují nejlepší cestu pro všechny následující: - Platby s minimalizací důvěry (bez kanálů, směrování nebo požadavků na likviditu) - Expresivita (pro ty, kteří ji chtějí) - Ochrana osobních údajů (plné virtuální počítače se ZK soukromí) - Dosažení všech výše uvedených cílů bez zavedení jakýchkoli exotických kryptografických předpokladů, důvěryhodných nastavení atd. Můžete se ptát na konečnost kvůli latenci L1, ale imo to lze docela jasně vyřešit do uspokojivé míry pomocí spojených sekvencerů pro rychlé předkonfekce. Takže máme všechny nástroje, co děláme pro to, abychom zajistili co nejlepší výsledek? Zatímco BTC by samozřejmě měl být měnou pro všechny tyto systémy (a platit za poplatky/plyn), je tu poslední (nebo možná první) otázka, jak toho všeho dosáhnout, aniž bychom zavedli L2 token z velké části kontrolovaný Nadací s příliš velkou kontrolou. Myslím, že systém pouze plateb může fungovat dobře bez tokenu správy (pouze s centrálním řazením + jednostrannými výstupy proti cenzuře), ale pochybuji o tom, že by to mělo něco výrazného. Zatímco většina nadací/DAO má za cíl decentralizaci, dát tolik moci do rukou centralizované organizace i ve fázi bootstrappingu se mi nezdá optimální, pokud chceme od samého začátku nějaký druh kolektivního přístupu, který zmírní rizika fragmentace. Bylo by skvělé slyšet, co si myslí ostatní lidé od lidí se zkušenostmi z jiných ekosystémů, jako je Ethereum, Celestia, Polygon, Cosmos, a také zvědaví, jak o těchto otázkách přemýšlejí současné L2 týmy pracující na Bitcoinu (např. Alpen, Chainway, Starkware). Neváhejte se ozvat v komentářích!</insert>