Esperaba que una cadena creada para mercados regulados incluyera, desde el inicio, una larga lista de contratos nativos. Cumplimiento, identidad, registro, todo, integrado en la génesis.
Dusk trae dos: Stake y Transfer.
Stake lleva el seguimiento de los proveedores, las participaciones, las recompensas y la gestión del conjunto de validadores. Transfer mueve DUSK y actúa como el punto de entrada para la ejecución de transacciones y el pago de gas.
Ese es todo el conjunto de génesis.
Todo lo regulado se sitúa encima. Zedger en DuskVM, Hedger en DuskEVM, Citadel para identidad, Dusk Trade como la superficie del producto. Nada de esto está soldado en la base.
El razonamiento que daría es que los requisitos cambian. Las reglas de elegibilidad, las obligaciones de divulgación y los formatos de reporte cambian con la regulación, y cualquier cosa que se defina en la génesis solo cambia con un hard fork. Poner la lógica de cumplimiento en la capa base significaría una cadena que necesita un fork cada vez que se actualiza una directiva.
El contrapunto, sin embargo, es real. Una base delgada significa que las garantías que a la gente realmente le importan viven en contratos que pueden actualizarse, y que la posibilidad de actualización es una promesa de seguridad distinta a la inmutabilidad.
¿Deberían estar las piezas que más probablemente van a cambiar lo más alejadas posible del consenso, o eso solo traslada el riesgo a algún lugar menos examinado?
¿Base delgada, o garantías delgadas?
#dusk @Dusk $DUSK