die 2 großen Gräben von @etherscan, von @SourcifyEth Entwickler @kaanuzdogan und die Lösungen dafür 1. Eine massive Datenbank von proprietären Smart Contracts mit Labels zu jedem als Entwickler, was ist das erste, was du tust, nachdem du einen Smart Contract gestartet hast? du lässt ihn auf etherscan verifizieren, da Menschen den Bytecode auf Ethereum nicht lesen können und wir wissen müssen, dass dein GitHub-Code der ist, der tatsächlich läuft das Verrückte ist, dass die gesamte Datenbank von verifizierten Smart Contracts von etherscan proprietär ist (du kannst manuell über ihr Frontend darauf zugreifen, aber Scraping ist illegal) was sie im Grunde in die Pole-Position für den Aufbau eines KI-Modells für das Codieren von Smart Contracts bringt, insbesondere da alle Labels ebenfalls proprietär sind das ist immer noch besser als solana, das keine Kultur der Quellcodeverifizierung hat 2. Etherscan hat massive Netzwerkeffekte, die sie nutzen, um sowohl API-Nutzer als auch Chains doppelt zu belasten zu ihrem Kredit wird es kostenlos für Ethereum gewartet aber L2s müssen 6-stellige Beträge pro Jahr zahlen und Nutzer, die sie über eine API abfragen, müssen ebenfalls zahlen Die Lösung? das einheitliche Verifizierungs-Plugin bei Remix (mit Hardhat und Foundry in Kürze) ermöglicht es dir, einmal zu laufen und überall zu verifizieren so würde es auf etherscan, sourcify, blockscout usw. angezeigt werden, ohne dass der Smart Contract-Entwickler jede Integration manuell vornehmen muss ähnlich sammelt @open_labels von @growthepie_eth Labels aus verschiedenen Quellen, sodass wir nicht auf eine geschlossene Datenbank angewiesen sind.