De 2 stora vallgravarna i @etherscan , från @SourcifyEth Dev @kaanuzdogan och lösningarna för det 1. En massiv databas med proprietära smarta kontrakt tillsammans med etiketter på varje Som utvecklare, vad är det första du gör efter att ha lanserat ett smart kontrakt? Du får det verifierat på Etherscan eftersom människor inte kan läsa bytekoden på Ethereum och vi behöver veta att din GitHub-kod är den som faktiskt körs Den galna delen är att Etherscans hela databas med verifierade smarta kontrakt är proprietär (du kan komma åt manuellt på deras frontend men skrapning är olagligt) vilket i princip sätter dem i pole position för att bygga en AI-modell för kodning av smarta kontrakt, särskilt eftersom alla etiketter också är proprietära Detta är fortfarande bättre än Solana som inte har en kultur av källkodsverifiering 2. Etherscan har massiva nätverkseffekter som de använder för att dubbelbelasta både API-användare och kedjor till deras kredit underhålls det fritt för Ethereum men L2:er måste betala 6-siffriga belopp per år och användare som frågar dem med ett API måste också betala Lösningen? Med plugin-programmet för enhetlig verifiering på Remix (med Hardhat och Foundry på gång) kan du köra en gång och verifiera överallt Så det skulle dyka upp på Ethernet, Sourcify, BlockScout, etc utan att Smart Contract Deployer manuellt integrerar varje På samma sätt samlar @open_labels by @growthepie_eth in etiketter från olika källor, så vi behöver inte förlita oss på en stängd databas