Gândindu-vă la următoarele: Să ne imaginăm că am avut OP_CAT și că ne-a oferit într-adevăr introspecție, STARKs + capacitate de purtare a stării (de a construi rollup-uri, validii etc), sau chiar alte coduri de operare care o rezolvă și mai bine (alegeți dintre OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV, <insert 64-bit="" arithmetic="" opcodes="" here="">) Cum ar arăta construcția ideală L2 pentru Bitcoin? Ce nu vrem să facem: să repetăm manualul Ethereum – 200 de echipe concurente care construiesc L2-uri diferite, interconectivitate/compoziție slabă, toate concurând pentru aceiași utilizatori, ce vrem să facem? Ce lecții putem învăța de la Ethereum? Rețineți că nu putem (și nici nu vrem) să facem rollup-uri bazate. L1 este prea lent pentru asta și nu vrem un MEV de această natură. De asemenea, rețineți că ne dorim: - Un sistem de tranzacții cu TPS ridicat (Lightning fără canale practic) - Unii vor dori mai multă expresivitate (pentru împrumuturi stablecoin fără încredere, swap-uri AMM, seifuri, planuri de moștenire, produse cu efect de levier) Dacă aceste două tipuri de sisteme există pe același strat de execuție, sau este cel mai bine să separăm plățile de aplicațiile cu cozi de secvențiere diferite (tind să cred că da) - poate vrem să mergem într-o direcție Celestia de a face un zkVM L2 și toate celelalte sisteme ca L3, cozi separate, dar agregare prin L2. A face rollup-uri reale pentru orice la scară este practic exclus pentru viziunea finală a jocului, având în vedere debitul scăzut al L1 și nevoile DA (iar adăugarea de blob-uri pare foarte puțin probabilă), așa că cel mai probabil am rula o anumită variantă de validiums + strat DA extern, zk-plasmas sau arhitecturi bazate pe validare pe partea clientului, cum ar fi Miden. De asemenea, ar trebui să explorăm dacă dorim sisteme ZK pure sau hibride ("ZK optimist", vezi Combustibil pentru ref) pentru a maximiza și mai mult randamentul. O modalitate este să lași piața liberă să câștige și să vezi ce se întâmplă, dar asta a făcut Ethereum. Chiar dacă luăm lecțiile cu noi și echipele încearcă să se coordoneze în jurul unor soluții de agregare singulare de la început, nu există nicio garanție că va funcționa. De asemenea, nu avem nicio capacitate de a consacra un anumit strat de execuție prin L1. Cu toate acestea, este clar pentru mine că STARK-urile reprezintă cea mai bună cale pentru toate următoarele: - Plăți reduse la minimum (fără canale, rutare sau cerințe de lichiditate) - Expresivitate (pentru cei care o doresc) - Confidențialitate (mașini virtuale ZK-privacy complete) - Realizarea tuturor celor de mai sus fără a introduce presupuneri criptografice exotice, configurații de încredere etc. S-ar putea să întrebați despre finalitate din cauza latenței L1, dar imo poate fi destul de clar abordată într-un grad satisfăcător cu secvențiere legate pentru pre-conf-uri rapide. Deci avem toate instrumentele, ce facem pentru a aranja cel mai bun rezultat posibil? În timp ce BTC ar trebui să fie moneda pentru toate aceste sisteme (și să plătească taxe/gaz), există ultima (sau poate prima) întrebare despre cum să realizăm toate acestea fără a introduce un token L2 controlat în mare parte de o fundație cu prea mult control. Cred că un sistem doar de plăți poate funcționa bine fără un token de guvernare (cu doar secvențiere centrală + ieșiri unilaterale împotriva cenzurii), dar mă îndoiesc de ceva expresiv. În timp ce majoritatea Fundațiilor/DAO-urilor au descentralizarea ca obiective, punerea atât de multă putere în mâinile unei organizații centralizate chiar și într-o fază de bootstrap mi se pare suboptimă dacă vrem un fel de abordare colectivă de la început pentru a atenua riscurile de fragmentare. Ar fi grozav să aud ce cred alți oameni de la oameni cu experiență din alte ecosisteme precum Ethereum, Celestia, Polygon, Cosmos și, de asemenea, curioși cum se gândesc echipele actuale L2 care lucrează la Bitcoin la aceste întrebări (de exemplu, Alpen, Chainway, Starkware). Vă rugăm să nu ezitați să interveniți în comentarii!</insert>