Siempre pensé que la lógica central de Dusk estaba en el algoritmo de consenso y en la máquina virtual, pero al revisar la arquitectura más profunda me di cuenta de que, en la parte más raíz del protocolo, en realidad se apoyan sobre dos contratos génesis: el contrato Stake y el contrato Transfer. Estas dos piezas son más fundamentales que el protocolo de consenso que se ve a simple vista.
El contrato Transfer se encarga de la entrada para el movimiento de activos: tanto si sigues las rutas de transacciones confidenciales de Phoenix como las rutas públicas de transacciones de Moonlight, al final el cambio de estado debe completarse a través de este contrato. Es también la puerta de entrada a la ejecución de contratos inteligentes; ya sea una transferencia normal o la llamada a un contrato, primero hay que pasar por aquí. En cambio, el contrato Stake hace un seguimiento específico de estados directamente ligados a la seguridad del consenso, como el provisioner, la cantidad apostada, la distribución de recompensas y el conjunto de validadores. Las penalizaciones de slashing de las que hablábamos antes, y también los cambios de estado que se activan en capas inferiores, se registran mediante este contrato.
Estos dos contratos se llaman "contratos génesis", lo que significa que no son contratos ordinarios que un desarrollador cualquiera pueda desplegar, sino una infraestructura fijada junto con el bloque de la cadena dentro del propio protocolo. En cierto sentido es similar a los módulos del núcleo en un sistema operativo tradicional: no pertenece al mismo nivel de privilegio que las aplicaciones de la capa superior. Entiendo la intención de este diseño así: las dos cosas —la transferencia de activos y la seguridad del consenso— están directamente relacionadas con las hipótesis más básicas de confianza de toda la cadena. Si esa lógica pudiera desplegarse, reemplazarse y modificarse como un contrato común, el límite de seguridad del sistema se volvería muy borroso. Al fijarlas en la capa del protocolo, se crea una especie de "cimiento inamovible"; todas las demás funciones se construyen sobre esa base.
Desde este ángulo, vuelvo a comprender la frontera entre "protocolo" y "aplicación". Cuando mucha gente habla de cadenas de contratos inteligentes, tiende a ver toda la lógica como "aplicaciones que corren encima". Pero en realidad, cómo fluyen los activos y cómo se mantiene el consenso no deberían depender de la lógica de una aplicación de capa ordinaria. Debe existir un límite inalterable que lo proteja, y el contrato Génesis es una manifestación concreta de ese límite.
#dusk $DUSK @Dusk
El contrato Transfer se encarga de la entrada para el movimiento de activos: tanto si sigues las rutas de transacciones confidenciales de Phoenix como las rutas públicas de transacciones de Moonlight, al final el cambio de estado debe completarse a través de este contrato. Es también la puerta de entrada a la ejecución de contratos inteligentes; ya sea una transferencia normal o la llamada a un contrato, primero hay que pasar por aquí. En cambio, el contrato Stake hace un seguimiento específico de estados directamente ligados a la seguridad del consenso, como el provisioner, la cantidad apostada, la distribución de recompensas y el conjunto de validadores. Las penalizaciones de slashing de las que hablábamos antes, y también los cambios de estado que se activan en capas inferiores, se registran mediante este contrato.
Estos dos contratos se llaman "contratos génesis", lo que significa que no son contratos ordinarios que un desarrollador cualquiera pueda desplegar, sino una infraestructura fijada junto con el bloque de la cadena dentro del propio protocolo. En cierto sentido es similar a los módulos del núcleo en un sistema operativo tradicional: no pertenece al mismo nivel de privilegio que las aplicaciones de la capa superior. Entiendo la intención de este diseño así: las dos cosas —la transferencia de activos y la seguridad del consenso— están directamente relacionadas con las hipótesis más básicas de confianza de toda la cadena. Si esa lógica pudiera desplegarse, reemplazarse y modificarse como un contrato común, el límite de seguridad del sistema se volvería muy borroso. Al fijarlas en la capa del protocolo, se crea una especie de "cimiento inamovible"; todas las demás funciones se construyen sobre esa base.
Desde este ángulo, vuelvo a comprender la frontera entre "protocolo" y "aplicación". Cuando mucha gente habla de cadenas de contratos inteligentes, tiende a ver toda la lógica como "aplicaciones que corren encima". Pero en realidad, cómo fluyen los activos y cómo se mantiene el consenso no deberían depender de la lógica de una aplicación de capa ordinaria. Debe existir un límite inalterable que lo proteja, y el contrato Génesis es una manifestación concreta de ese límite.
#dusk $DUSK @Dusk
