Los 2 grandes fosos de @etherscan , de @SourcifyEth @kaanuzdogan de desarrollo y las soluciones para ello 1. Una base de datos masiva de contratos inteligentes propietarios junto con etiquetas en cada uno Como desarrollador, ¿qué es lo primero que haces después de lanzar un contrato inteligente? Lo verificas en Etherscan ya que los humanos no pueden leer el código de bytes en Ethereum y necesitamos saber que tu código de GitHub es el que realmente se está ejecutando La parte loca es que toda la base de datos de contratos inteligentes verificados de Etherscan es propietaria (puede acceder manualmente en su frontend, pero el raspado es ilegal) lo que básicamente los coloca en la pole position para construir un modelo de IA para la codificación de contratos inteligentes, especialmente porque todas las etiquetas también son propietarias Esto sigue siendo mejor que Solana, que no tiene una cultura de verificación de código fuente 2. Etherscan tiene efectos de red masivos que utilizan para cobrar dos veces tanto a los usuarios de API como a las cadenas A su favor, se mantiene libremente para Ethereum pero los L2 tienen que pagar 6 cifras al año y los usuarios que los consultan con una API también deben pagar ¿La solución? el complemento de verificación unificada en Remix (con hardhat y foundry próximamente) le permite ejecutar una vez y verificar en todas partes Por lo tanto, aparecería en Etherscan, Sourcify, Blockscout, etc. sin que el implementador de contratos inteligentes integre manualmente cada uno Del mismo modo, el @open_labels by @growthepie_eth reúne etiquetas de diferentes fuentes, por lo que no necesitamos depender de una base de datos cerrada