El Libro Amarillo dice:
Estos son cuatro de los llamados contratos 'precompilados', concebidos como una pieza preliminar de arquitectura que luego pueden convertirse en extensiones nativas. Los cuatro contratos en las direcciones 1, 2, 3 y 4 ejecutan la función de recuperación de clave pública de curva elíptica, el esquema hash SHA2 de 256 bits, el esquema hash RIPEMD de 160 bits y la función de identidad, respectivamente.
¿Qué es un contrato precompilado y en qué se diferencia de los códigos de operación nativos? Si un contrato precompilado se convierte en una extensión nativa, ¿qué gana? Dado el uso generalizado de SHA2-256, ¿por qué no se implementó de forma nativa?
Aunque no sé la verdadera razón, intentaré adivinar. Habría las siguientes consideraciones:
Tamaño del espacio de nombres . No hay tantos códigos de operación posibles, por lo que estos deben asignarse con moderación. El espacio de las direcciones de los contratos, por otro lado, es prácticamente ilimitado para todos los efectos prácticos.
Riesgo de reutilización del nombre . Es un buen principio de ingeniería de software no reutilizar nombres (o códigos de operación), especialmente en el sistema donde no se controlan las actualizaciones.
utilidad _ Hay algunas operaciones que siempre son útiles, como operaciones aritméticas, juego de bits, control de flujo y otras. Las primitivas criptográficas, por otro lado, pueden resultar inadecuadas en el futuro, y en su lugar se usará algo más. Convertir estos primitivos en códigos de operación es correr el riesgo de gastar un valioso espacio de nombres en algo que podría volverse obsoleto.
Promoción suave de código popular/útil . Si ciertas cosas, por ejemplo, las operaciones de zkSNARK o la verificación de PoW de Dogecoin, comenzando con el código de solidez y luego parcialmente optimizado, se vuelven muy útiles y populares, podrían convertirse en contratos precompilados. Dicha promoción es un cambio mucho más suave en la red que la introducción de un nuevo código de operación.
No es una autoridad, pero conozco a alguien que es...
Del artículo de Vitalik, A Prehistory of the Ethereum Protocol
El segundo fue la idea de "precompilaciones", que resuelve el problema de permitir que los cálculos criptográficos complejos se puedan utilizar en el EVM sin tener que lidiar con la sobrecarga de EVM. También habíamos analizado muchas ideas más ambiciosas sobre "contratos nativos", donde si los mineros tienen una implementación optimizada de algunos contratos, podrían "votar" el precio del gas de esos contratos a la baja, por lo que los contratos que la mayoría de los mineros podrían ejecutar mucho más rápido naturalmente tendrían un precio de gasolina más bajo; sin embargo, todas estas ideas fueron rechazadas porque no pudimos encontrar una forma criptoeconómicamente segura de implementar tal cosa. Un atacante siempre podría crear un contrato que ejecute alguna operación criptográfica con trampilla, distribuir la trampilla entre ellos y sus amigos para permitirles ejecutar este contrato mucho más rápido, luego vote el precio de la gasolina hacia abajo y utilícelo para DoS en la red. En su lugar, optamos por el enfoque mucho menos ambicioso de tener un número menor de precompilaciones que simplemente se especifican en el protocolo, para operaciones comunes como hash y esquemas de firma.
No creo que haya una "respuesta correcta" sobre si una funcionalidad dada debe ser una compilación previa o nativa. Parece que se redujo a un juicio de diseño por todas las razones mencionadas anteriormente. A menos que VB o Gavofyork intervengan, nunca lo sabremos con seguridad...
T9b