#dusk $DUSK A las Dusk se les bloquea el tamaño a 1 MB.
Eso se traduce en aproximadamente 250 transacciones de Phoenix por bloque, según las propias notas de ingeniería de Dusk. Haz la división y una sola transferencia protegida ronda los 4 KB.

Una transferencia UTXO simple en una cadena transparente se sitúa por debajo de 500 bytes. La prueba PLONK en sí permanece compacta y de tamaño constante, con cerca de medio kilobyte incluso si el circuito se vuelve más complejo. Así que el peso extra no es la prueba. Es que una transferencia protegida tiene que llevar las notas, los nullifiers y los compromisos para que el gasto no pueda rastrearse hasta ninguna persona.

La privacidad se paga en bytes, no en cómputo.

Yo pensé que ese era todo el relato de escalabilidad hasta que me puse a profundizar en DuskEVM. Funciona sobre OP Stack, ejecutando transacciones EVM mientras un agregador publica los datos de la transacción de vuelta a DuskDS como blobs en lugar de hacerlo en Ethereum. Bien en el papel. Traslada la ejecución general de contratos fuera de la capa de asentamiento nativa de privacidad, dale su propio mercado de gas, y mantén DuskDS ligero.

Excepto que esos blobs todavía consumen el presupuesto de bloques de DuskDS. Son los mismos bytes finitos con los que las transferencias protegidas ya están peleando. Y ahora mismo, DuskEVM se ejecuta solo con el secuenciador, sin un mempool público

Así que el cuello de botella no desapareció. Se trasladó, y el ordenamiento se volvió más centralizado en el proceso. DUSK es el token de gas nativo en ambas capas, DuskDS y DuskEVM, así que su curva real de uso depende de si ese presupuesto compartido de bytes aguanta cuando el tráfico de EVM realmente aparece a escala.

¿Una cadena modular de privacidad resuelve la congestión al añadir capas, o solo la mueve a un lugar más difícil de comprobar?

#Dusk @Dusk