In Bangkok haben wir angekündigt, dass wir einen ernsthaften Blick unter die Haube der Beweissysteme werfen werden. Unser Ziel ist es, alle Vertrauensannahmen offenzulegen, diese Beweissysteme transparent zu machen und - am wichtigsten - allen Nutzern einfachen Zugang zum Quellcode der bewiesenen Programme zu geben. Der neue ZK-Katalog ist das Ergebnis monatelanger Arbeit, und das ist erst der Anfang.

Der Designraum der Ethereum-Rollups ist riesig. Ich werde nicht leugnen, dass die Bewertung von @0xFacet für das gesamte Team eine Herausforderung war, da sein Design nicht dem entspricht, was man von einem typischen Rollup erwarten würde. Dennoch lieben wir es, herausgefordert zu werden, und als Ergebnis sind einige neue Dashboards zu kanonischen und externen Brücken-Assets in Arbeit. Der herausforderndste Aspekt von @0xFacet ist zweifellos sein nicht-standardmäßiger Gas-Token. Seine Verwendung stellt die grundlegende Definition eines "kanonischen" Assets in Frage, da wir normalerweise annehmen, dass der Gas-Token kanonisch überbrückt werden muss. Aber was ist, wenn man den Gas-Token überhaupt nicht wirklich "überbrückt"? Was ist dann ein kanonisches Asset und eine kanonische Brücke? Lesen Sie die vollständige Bewertung und die Ankündigung von @0xFacet für weitere technische Details.

Ich sehe das ganz anders * Viele Projekte haben es geschafft, alle einer Gehirnwäsche zu unterziehen, dass das Posten von Daten an AWS oder 1/1 DAC "gut genug" ist. Den Endbenutzern ist es egal, aber wir (pro Community) sollten sie dazu bringen, sich dafür zu interessieren, indem wir solchen Architekturen dringend davon abraten. Stattdessen werden sie von einigen Rollup- und RaaS-Teams ermutigt * Der Preisfindungsmechanismus in Ethereum und Celestia ist abschreckend - Projekte wollen Web2-Preiszuverlässigkeit, damit sie einen niedrigen und vorhersehbaren Preis für ihre Nutzer aufrechterhalten können. Plötzliche Preisspitzen sind nicht akzeptabel, wenn Sie in großem Maßstab arbeiten * DA-Projekte sollten sich auf die Förderung legitimer Anwendungsfälle konzentrieren und nicht auf zentralisierte Projekte, die sich nicht einmal die Mühe machen, ihren Code zu veröffentlichen, damit die Community ihre Behauptungen überprüfen kann. Wenn wir nur Hyperliquid-Klone bauen, werden wir alle auf Null gehen. Niemand will auf lange Sicht einen zentralisierten, verwahrten Austausch, der vorgibt, dezentralisiert zu sein * Angriffe auf das Zurückhalten von Daten (buchstäblich der Hauptgrund für die Verwendung von DA) sind den Benutzern schwer zu erklären - wir könnten mehr Aufklärung und generell das Bewusstsein der Community für ein Problem gebrauchen. Die überwiegende Mehrheit der Pro-Benutzer sieht den Unterschied zwischen Datenveröffentlichung und Datenabruf nicht. Nicht-Pro-Benutzer sehen überhaupt kein Problem, da für sie Daten immer verfügbar zu sein scheinen, so dass es schwierig ist, ihnen zu erklären, welches Problem wir hier zu lösen versuchen