as duas grandes barreiras do @etherscan, do desenvolvedor @SourcifyEth @kaanuzdogan e as soluções para isso 1. Um enorme banco de dados de contratos inteligentes proprietários junto com rótulos em cada um deles como desenvolvedor, qual é a primeira coisa que você faz após lançar um contrato inteligente? você o verifica no etherscan, já que os humanos não conseguem ler o código byte no ethereum e precisamos saber que seu código do github é o que realmente está em execução a parte louca é que todo o banco de dados de contratos inteligentes verificados do etherscan é proprietário (você pode acessá-lo manualmente em sua interface, mas a raspagem é ilegal) o que basicamente os coloca em posição de vantagem para construir um modelo de IA para codificação de contratos inteligentes, especialmente porque todos os rótulos também são proprietários isso ainda é melhor do que a solana, que não tem uma cultura de verificação de código fonte 2. O etherscan tem enormes efeitos de rede que eles usam para cobrar em dobro tanto os usuários da API quanto as cadeias para seu crédito, é mantido gratuitamente para o ethereum mas os L2s têm que pagar seis dígitos por ano e os usuários que os consultam com uma API também precisam pagar A solução? o plugin de verificação unificada no Remix (com hardhat e foundry a caminho) permite que você execute uma vez e verifique em todos os lugares então ele apareceria no etherscan, sourcify, blockscout, etc., sem que o implantador do contrato inteligente integrasse manualmente cada um de forma semelhante, os @open_labels do @growthepie_eth reúnem rótulos de diferentes fontes para que não precisemos depender de um banco de dados fechado