#dusk $DUSK @Dusk Algo sobre el diseño de almacenamiento de Dusk me molesta, pero de una buena manera. Piecrust, su VM, escribe estado en el disco en fragmentos de 64KB que son páginas completas de memoria WASM. Ethereum escribe en ranuras de 32 bytes. Eso es, aproximadamente, una brecha de 2.000x en granularidad, solo para actualizar un valor.
¿Por qué tan tosco? Dusk no usa en absoluto la API de almacenamiento de pares clave-valor. La memoria completa de un contrato es su estado. Escribe una estructura simple de Rust, usa un BTreeMap y se persiste automáticamente, sin contabilidad tipo SSTORE. Para equipos que vienen de las finanzas tradicionales en vez de Solidity, esto es realmente más fácil para desarrollar.
Pero la persistencia de memoria completa no escala gratis, y el equipo claramente llegó a ese límite. Construyeron un seguimiento de páginas sucias para que solo se reescriban las páginas que cambiaron en lugar de reescribir todo el snapshot cada vez. Arreglo inteligente. Aun así, la unidad de «cambiado» es una página de 64KB, no unos pocos bytes. Un libro mayor con miles de entradas, tocadas por una sola transacción, aún podría dejar varias páginas dispersas marcadas como sucias solo por cómo el asignador distribuye la memoria. Parece un intercambio real, no un problema resuelto.
Todavía no he visto benchmarks de carga sobre esto. Así que, de verdad, me da curiosidad: ¿alguien ha sometido a Piecrust a pruebas de presión con tráfico real de liquidaciones de alta frecuencia?
¿Por qué tan tosco? Dusk no usa en absoluto la API de almacenamiento de pares clave-valor. La memoria completa de un contrato es su estado. Escribe una estructura simple de Rust, usa un BTreeMap y se persiste automáticamente, sin contabilidad tipo SSTORE. Para equipos que vienen de las finanzas tradicionales en vez de Solidity, esto es realmente más fácil para desarrollar.
Pero la persistencia de memoria completa no escala gratis, y el equipo claramente llegó a ese límite. Construyeron un seguimiento de páginas sucias para que solo se reescriban las páginas que cambiaron en lugar de reescribir todo el snapshot cada vez. Arreglo inteligente. Aun así, la unidad de «cambiado» es una página de 64KB, no unos pocos bytes. Un libro mayor con miles de entradas, tocadas por una sola transacción, aún podría dejar varias páginas dispersas marcadas como sucias solo por cómo el asignador distribuye la memoria. Parece un intercambio real, no un problema resuelto.
Todavía no he visto benchmarks de carga sobre esto. Así que, de verdad, me da curiosidad: ¿alguien ha sometido a Piecrust a pruebas de presión con tráfico real de liquidaciones de alta frecuencia?
