@Dusk_Foundation La constitución fundacional de un país existe en el mismo momento en que existe el país: nadie la vota para que aparezca después; simplemente está ahí desde el primer día, y todo lo demás se construye tomando como referencia esa base.
Los contratos de génesis de Dusk funcionan de la misma manera. Los materiales de arquitectura propios de Dusk describen dos: el contrato de stake, que sigue qué provisioners están haciendo staking, registra recompensas y habilita acciones de hacer stake, retirarlo (unstake) y retirar recompensas; y el contrato de transferencia, que gestiona tanto las transferencias Moonlight (públicas) como Phoenix (protegidas), paga el gas y actúa como punto de entrada para la ejecución de transacciones directamente en DuskDS.
Ese papel fundacional se extiende más allá de DuskDS por sí solo, aunque el mecanismo exacto difiere según la capa. DuskEVM, según los propios documentos de Dusk, mueve DUSK para el gas a través de su propio puente hacia la L1 de Dusk, y finalmente vuelve a asentarse en DuskDS: una ruta relacionada pero distinta del rol directo del contrato de transferencia en las transacciones nativas de DuskDS. Ambos caminos regresan a la misma capa base; no son mecanismos idénticos. #dusk
Autocrítica: la analogía con la constitución tiene un límite real que vale la pena nombrar. La constitución de un país puede modificarse formalmente mediante un proceso definido. Lo que no he encontrado documentado es si los contratos de génesis de Dusk siguen una ruta de enmienda equivalente y claramente especificada, o si "génesis" aquí significa funcionalmente que es permanente por diseño: una pregunta de gobernanza real, dado cuánto de la ampliación del stack multilayer de Dusk ahora depende de que esos dos contratos sigan siendo correctos. $DUSK
DUSK debería evaluarse en función de si esa ambigüedad se aclara antes de que esos contratos alguna vez necesiten actualizarse bajo una presión real, no después.
#dusk $DUSK @Dusk
Los contratos de génesis de Dusk funcionan de la misma manera. Los materiales de arquitectura propios de Dusk describen dos: el contrato de stake, que sigue qué provisioners están haciendo staking, registra recompensas y habilita acciones de hacer stake, retirarlo (unstake) y retirar recompensas; y el contrato de transferencia, que gestiona tanto las transferencias Moonlight (públicas) como Phoenix (protegidas), paga el gas y actúa como punto de entrada para la ejecución de transacciones directamente en DuskDS.
Ese papel fundacional se extiende más allá de DuskDS por sí solo, aunque el mecanismo exacto difiere según la capa. DuskEVM, según los propios documentos de Dusk, mueve DUSK para el gas a través de su propio puente hacia la L1 de Dusk, y finalmente vuelve a asentarse en DuskDS: una ruta relacionada pero distinta del rol directo del contrato de transferencia en las transacciones nativas de DuskDS. Ambos caminos regresan a la misma capa base; no son mecanismos idénticos. #dusk
Autocrítica: la analogía con la constitución tiene un límite real que vale la pena nombrar. La constitución de un país puede modificarse formalmente mediante un proceso definido. Lo que no he encontrado documentado es si los contratos de génesis de Dusk siguen una ruta de enmienda equivalente y claramente especificada, o si "génesis" aquí significa funcionalmente que es permanente por diseño: una pregunta de gobernanza real, dado cuánto de la ampliación del stack multilayer de Dusk ahora depende de que esos dos contratos sigan siendo correctos. $DUSK
DUSK debería evaluarse en función de si esa ambigüedad se aclara antes de que esos contratos alguna vez necesiten actualizarse bajo una presión real, no después.
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
13 hora(s) restante(s)