#dusk $DUSK
Los detalles técnicos de esta máquina virtual Dusk son, cuanto más la analizo, más me abruman.
Al principio me quedé intrigado: ¿dónde se guardan esos estados de las posiciones y permisos dentro del contrato? Después de darles vueltas mucho tiempo, lo entendí: mete todo el estado del contrato en un bloque de memoria contigua; cada vez que lo modifica, reescribe de nuevo todo ese bloque de memoria. No tiene nada que ver con EVM, por cómo funciona. En EVM, cambias dónde corresponde: si editas un documento, solo cambias esa línea; pero aquí, aunque solo cambies un número, hay que reconstruir y reescribir toda la página de memoria.
Esto ya consume recursos de por sí, y encima incorpora un diseño de doble libro contable. Publica uno para que lo vea el regulador y el libro privado corre en XSC. En cada transacción, el estado público se actualiza una vez y el estado privado se vuelve a generar una vez: las dos copias en memoria tienen que volver a escribirse. Además, del lado de Hedger se ejecuta otra vez una prueba de conocimiento cero; los nodos vuelven a recalcularla. Resulta que el coste no se suma “1+1”, sino que se multiplica.
En los tokens securitizados, esas reglas de posiciones, listas blancas y bloqueos: el estado, por naturaleza, solo puede aumentar y no disminuir. Si despliegas un contrato XSC de cierta complejidad, aunque solo cambies un saldo, toda la página de memoria se reescribe por completo.
Alguien seguro dirá: “y qué, el estado corre en capas superiores; la capa base DuskDS solo guarda pruebas”. Esa frase suena razonable, pero al pensar con calma no lo es. ¿Los nodos de archivo no guardan instantáneas históricas de memoria? Entonces, ¿cómo van a auditar el pasado? ¿Qué se supone que van a revisar: el aire? Si las guardan, ¿en qué se diferencia de tener nodos completos? En realidad, el problema de apilar cada vez más estado se está simplemente trasladando de la capa de ejecución a la capa de archivo. El equipo oficial habla de esto una y otra vez, pero no da ni una respuesta directa de cara al tema.
Ahora estoy más pendiente de cómo van realmente los contratos de valores de NPEX en cadena. Si en medio año el tamaño del estado de un solo contrato llega a ser 10 veces mayor que el de un ERC20 normal, o si los nodos de archivo empiezan a guardar sigilosamente instantáneas de memoria, entonces este diseño es una bomba para RWA y no lo tocaré.
¡Ah, por cierto! Hay otro agujero: la prueba concisa de DuskDS puede demostrar que el libro contable privado en sí es correcto, pero ¿puede demostrar que el historial de cada instantánea de memoria está encadenado y nunca se ha modificado? Si no puede, la pista de auditoría de los valores tokenizados se corta directamente entre la capa de privacidad y la de archivo.
@Dusk
Los detalles técnicos de esta máquina virtual Dusk son, cuanto más la analizo, más me abruman.
Al principio me quedé intrigado: ¿dónde se guardan esos estados de las posiciones y permisos dentro del contrato? Después de darles vueltas mucho tiempo, lo entendí: mete todo el estado del contrato en un bloque de memoria contigua; cada vez que lo modifica, reescribe de nuevo todo ese bloque de memoria. No tiene nada que ver con EVM, por cómo funciona. En EVM, cambias dónde corresponde: si editas un documento, solo cambias esa línea; pero aquí, aunque solo cambies un número, hay que reconstruir y reescribir toda la página de memoria.
Esto ya consume recursos de por sí, y encima incorpora un diseño de doble libro contable. Publica uno para que lo vea el regulador y el libro privado corre en XSC. En cada transacción, el estado público se actualiza una vez y el estado privado se vuelve a generar una vez: las dos copias en memoria tienen que volver a escribirse. Además, del lado de Hedger se ejecuta otra vez una prueba de conocimiento cero; los nodos vuelven a recalcularla. Resulta que el coste no se suma “1+1”, sino que se multiplica.
En los tokens securitizados, esas reglas de posiciones, listas blancas y bloqueos: el estado, por naturaleza, solo puede aumentar y no disminuir. Si despliegas un contrato XSC de cierta complejidad, aunque solo cambies un saldo, toda la página de memoria se reescribe por completo.
Alguien seguro dirá: “y qué, el estado corre en capas superiores; la capa base DuskDS solo guarda pruebas”. Esa frase suena razonable, pero al pensar con calma no lo es. ¿Los nodos de archivo no guardan instantáneas históricas de memoria? Entonces, ¿cómo van a auditar el pasado? ¿Qué se supone que van a revisar: el aire? Si las guardan, ¿en qué se diferencia de tener nodos completos? En realidad, el problema de apilar cada vez más estado se está simplemente trasladando de la capa de ejecución a la capa de archivo. El equipo oficial habla de esto una y otra vez, pero no da ni una respuesta directa de cara al tema.
Ahora estoy más pendiente de cómo van realmente los contratos de valores de NPEX en cadena. Si en medio año el tamaño del estado de un solo contrato llega a ser 10 veces mayor que el de un ERC20 normal, o si los nodos de archivo empiezan a guardar sigilosamente instantáneas de memoria, entonces este diseño es una bomba para RWA y no lo tocaré.
¡Ah, por cierto! Hay otro agujero: la prueba concisa de DuskDS puede demostrar que el libro contable privado en sí es correcto, pero ¿puede demostrar que el historial de cada instantánea de memoria está encadenado y nunca se ha modificado? Si no puede, la pista de auditoría de los valores tokenizados se corta directamente entre la capa de privacidad y la de archivo.
@Dusk