Designutrymmet för Ethereum-rollups är enormt. Jag tänker inte förneka att det var en utmaning för hela teamet att bedöma @0xFacet eftersom dess design inte är vad man kan förvänta sig av en typisk rollup. Ändå älskar vi att bli utmanade och som ett resultat av detta är några nya instrumentpaneler relaterade till kanoniska och externt överbryggade tillgångar på gång. Den mest utmanande aspekten av @0xFacet är utan tvekan dess icke-standardiserade gastoken. Dess användning utmanar den grundläggande definitionen av en "kanonisk" tillgång, eftersom vi normalt antar att gastoken måste överbryggas kanoniskt, men vad händer om du inte riktigt "överbryggar" gastoken alls? Vad är då en kanonisk tillgång och kanonisk bro? Läs hela recensionen och @0xFacet tillkännagivandet för mer teknisk information.

Jag har en helt annan uppfattning * många projekt lyckades hjärntvätta alla att det är "tillräckligt bra att posta data till AWS eller 1/1 DAC". Slutanvändare bryr sig inte, men vi (pro-communityn) bör få dem att bry sig genom att starkt avråda från sådana arkitekturer. I stället uppmuntras de faktiskt av vissa rollup- och RaaS-team * Prisupptäcktsmekanismen i Ethereum och Celestia är avskräckande - projekt vill ha Web2-pristillförlitlighet så att de kan hålla ett lågt och förutsägbart pris för sina användare. Plötsliga pristoppar är inte acceptabla när du arbetar i stor skala * DA-projekt bör fokusera på att främja legitima användningsfall och inte centraliserade projekt som inte ens bryr sig om att publicera sin kod så att communityn kan kontrollera deras påståenden. Om allt vi bygger är Hyperliquid-kloner kommer vi alla att gå till noll. Ingen vill på lång sikt ha ett centraliserat depåutbyte som utger sig för att vara decentraliserat * Attacker med att undanhålla data (bokstavligen den främsta anledningen till att använda DA) är svåra att förklara för användarna - vi skulle behöva mer utbildning och i allmänhet samhällets medvetenhet om ett problem. De allra flesta proffsanvändare ser inte skillnaden mellan datapublicering och datahämtning. Icke-proffsanvändare ser inget problem alls eftersom data för dem "verkar" alltid vara tillgängliga, så det är svårt att förklara för dem vilket problem vi försöker lösa här

Varför du bör kontrollera @cartesiproject * Att ha en honungskruka för att uppmuntra hackare att bryta systemet är mycket bättre än att ha EOA med uppgraderingsbefogenheter för betalansering * Om du arbetar som du är tänkt har du en SDK till ditt förfogande för att snabbt och billigt bygga anpassade AppChains som enkelt kan vara Stage1 eller Stage2 vid lanseringen. Cpp-koden för honeypot är minimal, kolla in den * Eftersom det är optimistiskt finns det inget behov för dig att köra komplicerad provdrift infra så kostnaderna för att driva kedjan är minimala och du kan göra den helt tillståndslös från dag 1 Nu behöver vi mer pengar i en honungskruka och forskare/hackare som är villiga att titta på sitt nya bedrägerisäkra system

Studera antaganden om L2-tillit. Utgå alltid från det värsta. Agera i enlighet med detta. Säkerhet och decentralisering spelar ingen roll förrän det gör det.

Är alt-DA L2s ett misslyckat experiment vid skalning av Ethereum? För några månader sedan meddelade @l2beat att ha en urusel DA-inställning där en eller två adresser kan täcka alla användares pengar, en praxis som blev utbredd i utrymmet, kommer att resultera i en förändring av klassificeringen av dessa system. De kommer inte längre att betraktas som Validium/Optimiums. Jag är övertygad om att vi, som community, vill ha system som ger användarna vissa minimigarantier för säkerhet och decentralisering, och det innebär att vi måste ha ett bevissystem och - om data inte skickas till Ethereum - ha några grundläggande garantier om datatillgänglighet. Det visar sig att projektet inte bryr sig. De bryr sig inte eftersom deras enda mål var att få lite VC-pengar och få minsta möjliga uppmärksamhet från användaren bara för att lansera en token på ett sätt som är så billigt som möjligt. I praktiken innebär detta att du använder en av RaaS-leverantörerna och absolut inte betalar Ethereum för data. Om de använde @celestia, @AvailProject eller @eigen_da brydde de sig inte om att "informera" Ethereum bridge om det, vilket gjorde alla medel i bron från Ethereum lätta att robusta. Dessa projekt kommer snart att blekna bort - de flesta är redan spökkedjor utan någon aktivitet. Men kanske är vissa projekt legitima men användarna bryr sig helt enkelt inte. I det här fallet är beslutet att inte säkra Ethereum bridge ett medvetet designval - men det finns mycket bättre arkitekturdesign än att lansera en helt osäker "L2" på RaaS. För två år sedan tydde alla tecken på att vi skulle ha tusentals rollups och att @l2beat inte skulle kunna hänga med. Nu verkar det mer troligt att vi kan se en motsatt trend - bara ett par dussin riktigt bra projekt och en enorm kyrkogård av misslyckade projekt som ingen ville ha från början.

Sedan en tid tillbaka spårar @l2beat DA-användning för olika DA-lager och projekt. Om du är intresserad av hur den senaste Pectra-uppgraderingen påverkade Ethereum blob-utrymme, kolla in

Vad är din magkänsla när det gäller säkerheten på bron som påstår sig använda MPC? Skulle du lita på det (bror, flerpartsberäkning, månmatematik, det måste vara säkert, nej?) eller du är skeptisk (vem i är undertecknarna?). Kontrollera innan du 🧵 svarar

AnyTrust-kedjor från @arbitrum introducerades redan 2022. De har då argumenterat för att det är en bra säkerhetsmodell att ha, låt oss säga, 20 kommittémedlemmar med antagandet att bara två är ärliga. Och det är svårt att argumentera

Det har gått exakt ett år nu sedan @Immutable (powered by @0xpolygon) tillkännagav sin zkEVM-kedja. Du kan kolla dokumenten för att lära dig mer om deras zk-teknik

En (inte så) kort förklaring till varför vi har introducerat namnet "AppChain" i Stages-systemet