de 2 grote verdedigingslinies van @etherscan, van @SourcifyEth ontwikkelaar @kaanuzdogan en de oplossingen daarvoor 1. Een enorme database van eigendoms-smart contracts met labels op elk als ontwikkelaar, wat is het eerste dat je doet na het lanceren van een smart contract? je laat het verifiëren op etherscan aangezien mensen de bytecode op ethereum niet kunnen lezen en we moeten weten dat jouw github-code de code is die daadwerkelijk draait de gekke kant is dat de hele database van etherscan met geverifieerde smart contracts eigendom is (je kunt het handmatig op hun frontend benaderen, maar scrapen is illegaal) wat hen in feite in pole position plaatst voor het bouwen van een AI-model voor smart contract codering, vooral omdat alle labels ook eigendom zijn dit is nog steeds beter dan solana, dat geen cultuur van broncodeverificatie heeft 2. Etherscan heeft enorme netwerkeffecten die ze gebruiken om zowel API-gebruikers als ketens dubbel te laten betalen terwijl het voor ethereum gratis wordt onderhouden maar L2's moeten 6 cijfers per jaar betalen en gebruikers die hen met een API raadplegen moeten ook betalen De oplossing? de uniforme verificatieplugin bij Remix (met hardhat en foundry in aantocht) laat je één keer draaien en overal verifiëren dus het zou verschijnen op etherscan, sourcify, blockscout, enz. zonder dat de smart contract-deployers handmatig elke integreren evenzo verzamelt de @open_labels van @growthepie_eth labels uit verschillende bronnen zodat we niet afhankelijk hoeven te zijn van een gesloten database