@Dusk
En algún lugar del diseño de Piecrust hay una admisión silenciosa de que el sandbox no es el lugar adecuado para todo.
Los contratos se ejecutan como WebAssembly, lo que le da a la VM su entorno de ejecución controlado.
Lo interesante es cuánto del trabajo pesado nunca toca ese entorno WASM.
El hashing se calcula de forma nativa.
También la verificación de pruebas ZK, tanto PlonK como Groth16.
Las comprobaciones de firma también: Schnorr y BLS.
Nada de eso se ejecuta dentro del sandbox que ejecuta el contrato.
La razón es un número, y es uno bastante aproximado.
Investigación citada por Dusk sitúa a WASM entre un 45 y un 255 por ciento más lento que el código nativo cuando las operaciones se vuelven complejas. La verificación criptográfica es exactamente el tipo de trabajo donde esa diferencia importa.
Aplicar esa penalización en cada transacción no era un trato que Dusk estuviera dispuesto a hacer, así que esas operaciones se gestionan mediante funciones nativas del host.
Esto es lo que me dejó pensando.
Las operaciones que se extraen no son aleatorias.
Hashing, verificación de pruebas, firmas: es gran parte de la maquinaria criptográfica de la que dependen aplicaciones centradas en la privacidad como Phoenix y Zedger.
El sandbox gestiona la lógica del contrato.
Las matemáticas de la privacidad se ejecutan en otro lugar.
Así que en realidad no hay un único límite de ejecución. Está el límite general de la VM y, luego, salidas deliberadas para las operaciones donde la ejecución nativa importa más.
Lo que todavía quiero entender es qué mantiene esa ruta nativa determinista en cada nodo. WASM te ofrece un entorno de ejecución muy explícito; una vez que un contrato llama fuera de ese entorno, ¿qué garantiza que cada nodo siga llegando exactamente al mismo resultado?
$DUSK me resulta aún más interesante cuando esa pregunta tiene una respuesta real detrás, no solo una función nativa que hace el trabajo más rápido.
#dusk
En algún lugar del diseño de Piecrust hay una admisión silenciosa de que el sandbox no es el lugar adecuado para todo.
Los contratos se ejecutan como WebAssembly, lo que le da a la VM su entorno de ejecución controlado.
Lo interesante es cuánto del trabajo pesado nunca toca ese entorno WASM.
El hashing se calcula de forma nativa.
También la verificación de pruebas ZK, tanto PlonK como Groth16.
Las comprobaciones de firma también: Schnorr y BLS.
Nada de eso se ejecuta dentro del sandbox que ejecuta el contrato.
La razón es un número, y es uno bastante aproximado.
Investigación citada por Dusk sitúa a WASM entre un 45 y un 255 por ciento más lento que el código nativo cuando las operaciones se vuelven complejas. La verificación criptográfica es exactamente el tipo de trabajo donde esa diferencia importa.
Aplicar esa penalización en cada transacción no era un trato que Dusk estuviera dispuesto a hacer, así que esas operaciones se gestionan mediante funciones nativas del host.
Esto es lo que me dejó pensando.
Las operaciones que se extraen no son aleatorias.
Hashing, verificación de pruebas, firmas: es gran parte de la maquinaria criptográfica de la que dependen aplicaciones centradas en la privacidad como Phoenix y Zedger.
El sandbox gestiona la lógica del contrato.
Las matemáticas de la privacidad se ejecutan en otro lugar.
Así que en realidad no hay un único límite de ejecución. Está el límite general de la VM y, luego, salidas deliberadas para las operaciones donde la ejecución nativa importa más.
Lo que todavía quiero entender es qué mantiene esa ruta nativa determinista en cada nodo. WASM te ofrece un entorno de ejecución muy explícito; una vez que un contrato llama fuera de ese entorno, ¿qué garantiza que cada nodo siga llegando exactamente al mismo resultado?
$DUSK me resulta aún más interesante cuando esa pregunta tiene una respuesta real detrás, no solo una función nativa que hace el trabajo más rápido.
#dusk
