Solía trabajar a tiempo parcial en un restaurante durante la universidad. La cocina estaba detrás de un muro. Los clientes podían ver el menú, hacer pedidos y recibir comida. No podían ver cómo se preparaba, qué equipo se usaba, ni qué proveedor entregó los ingredientes esa mañana. El comedor y la cocina eran dos espacios completamente separados. Si la cocina se incendiaba, el comedor no lo sabría hasta que alguien saliera y dijera algo. Y si en el comedor había mucho ruido, a la cocina no le importaba: seguían cocinando.
Esa separación es exactamente lo que la mayoría de las blockchains monolíticas no tienen. En Ethereum, la ejecución, el almacenamiento de datos y la liquidación ocurren en la misma capa. Si el procesamiento de transacciones se ralentiza, la liquidación también se ralentiza. Si el almacenamiento de datos se llena, la ejecución se resiente. Todo está enredado en una sola habitación.
@Dusk_Foundation separa esto con DuskDS, una capa dedicada de Datos y Liquidación que opera de forma independiente del entorno de ejecución. Piensa en construir la cocina y el comedor como estructuras separadas con una ventana de paso controlada. La capa de ejecución gestiona la lógica de los contratos inteligentes. DuskDS se encarga de dónde viven los datos y de cómo se alcanza la finalidad. Una puede actualizarse u optimizarse sin interrumpir la otra.
Autocrítica: la separación de capas suena limpia en los diagramas de arquitectura. En la práctica, la "ventana de paso" entre la ejecución y la liquidación introduce su propia complejidad. Si las dos capas procesan a velocidades diferentes, aparece una cuestión de sincronización: ¿qué ocurre con un contrato inteligente que lee datos de liquidación que van un bloque por detrás del estado de ejecución? La analogía del restaurante se mantiene hasta que te das cuenta de que a veces la cocina necesita saber cuántos asientos están ocupados en tiempo real, y un muro hace eso más difícil, no más fácil.
$DUSK debe evaluarse según qué tan bien sus capas separadas manejan la sincronización del estado bajo carga, no solo según lo limpia que se vea la separación arquitectónica en el papel.
$HEMI $H #dusk
Esa separación es exactamente lo que la mayoría de las blockchains monolíticas no tienen. En Ethereum, la ejecución, el almacenamiento de datos y la liquidación ocurren en la misma capa. Si el procesamiento de transacciones se ralentiza, la liquidación también se ralentiza. Si el almacenamiento de datos se llena, la ejecución se resiente. Todo está enredado en una sola habitación.
@Dusk_Foundation separa esto con DuskDS, una capa dedicada de Datos y Liquidación que opera de forma independiente del entorno de ejecución. Piensa en construir la cocina y el comedor como estructuras separadas con una ventana de paso controlada. La capa de ejecución gestiona la lógica de los contratos inteligentes. DuskDS se encarga de dónde viven los datos y de cómo se alcanza la finalidad. Una puede actualizarse u optimizarse sin interrumpir la otra.
Autocrítica: la separación de capas suena limpia en los diagramas de arquitectura. En la práctica, la "ventana de paso" entre la ejecución y la liquidación introduce su propia complejidad. Si las dos capas procesan a velocidades diferentes, aparece una cuestión de sincronización: ¿qué ocurre con un contrato inteligente que lee datos de liquidación que van un bloque por detrás del estado de ejecución? La analogía del restaurante se mantiene hasta que te das cuenta de que a veces la cocina necesita saber cuántos asientos están ocupados en tiempo real, y un muro hace eso más difícil, no más fácil.
$DUSK debe evaluarse según qué tan bien sus capas separadas manejan la sincronización del estado bajo carga, no solo según lo limpia que se vea la separación arquitectónica en el papel.
$HEMI $H #dusk