¿Cómo hago que mi DAPP sea "a prueba de serenidad"?

Cuando llegue Serenity, la red sufrirá muchos cambios, algunos de los cuales pueden tener consecuencias inesperadas en los contratos inteligentes existentes. ¿Cómo puedo planificar para estar mejor preparado para aprovechar las nuevas funciones de Serenity y tener menos probabilidades de encontrar errores inesperados y fallas de seguridad?

Respuestas (1)

Todavía no es seguro, pero:

  1. NO confíe en cálculos muy detallados de los costos actuales del gas. Suponga que los costos de gas de las llamadas por contrato pueden aumentar o disminuir hasta en un orden de magnitud en una futura bifurcación dura.
  2. Si crea contratos en ensamblaje (es decir, no serpiente, solidez o LLL), NO use operaciones JUMP/JUMPI dinámicas (es decir, cada JUMP/JUMPI debe estar inmediatamente precedido por un valor PUSH que especifique el punto exacto en el código al que saltar)
  3. NO hagas nada importante basado en el código de operación de DIFICULTAD.
  4. NO confíe en la suposición de un tiempo de bloqueo entre 12 y 20 segundos.
  5. NO asuma que los BLOCKHASHes serán una fuente confiable de aleatoriedad.
  6. NO asuma que tx.origin seguirá siendo utilizable o significativo.
  7. NO asuma que los códigos de operación que no sean 0xfe seguirán siendo inválidos.

No es seguro que se requieran todos esos pasos, o que sean suficientes, pero eso debería llevarlo a la mayor parte del camino.

Entonces, si tx.origin no es significativo, ¿lo seguirá siendo msg.sender?
Sí, msg.sender seguirá siendo significativo.
¿Deberíamos agregar: "NO transmita que 0x0 nunca puede ser un msg.sender?" - ¿O es esta la idea de la mesa?
Es probable que hagamos que el punto de entrada sea diferente a 0x0 si vemos que muchas aplicaciones usan 0x0 como sustituto de "todavía no existe una cuenta en esta ranura" hasta el punto en que hacer que 0x0 sea el punto de entrada compromete la seguridad.
¿Por qué los blockhashes no son una fuente confiable de aleatoriedad?
@VitalikButerin ¿Cuál es una fuente confiable del iniciador de una cadena de llamadas en el futuro si no es tx.origin?
@VitalikButerin, ¿cómo evitamos que los contratos se conviertan en destinatarios de valor, es decir, la función de respaldo malicioso arroja patrones de envío, sin requerir tx.origin == remitente del mensaje?
@VitalikButerin y otro grande... NO confíe en que el número de bloque o las variables sean consistentes en todos los contratos. En este momento, es básicamente una cadena de bloques global para todos los contratos, por lo que mientras se ejecuta su transacción, puede confiar en que las variables en otros fragmentos sean consistentes. Pero en el escenario fragmentado, ¿podemos tener condiciones de carrera ENTRE fragmentos, o todavía actúa en modo ACID completo como si hubiera una cadena de bloques gigante y los números de bloque aumentaran monótonamente en todos los fragmentos como antes? ¿Se verá igual desde el interior del EVM?
¿Cómo hago que mi DAPP sea "a prueba de serenidad"?
RespuestasAquíPolítica de privacidad1y, 0v