A Q observa cómo las cadenas públicas compiten durante años por la velocidad de producción de bloques y el rendimiento, pero en el contexto de la liquidación de valores, ninguno de estos dos indicadores es lo primero. Lo verdaderamente clave es la finalización: después de que una transacción se confirma, ¿puede garantizarse que en cualquier circunstancia no se revertirá. El diseño de consenso de @Dusk coloca este asunto en el nivel de prioridad más alto.
La razón es muy práctica. En los sistemas de compensación tradicionales, cuando la entrega se completa, significa la transferencia de propiedad con efectos jurídicos, y sobre ese estado se construyen los dividendos posteriores, las operaciones de embargo y la pignoración. Si el libro contable pudiera reorganizarse debido a una bifurcación, incluso si la probabilidad es extremadamente baja, el área legal y el cumplimiento no lo pueden aceptar. Esto es totalmente distinto al escenario de las transferencias; aquí no aplica la idea de “esperar unas cuantas confirmaciones”.
Buscar una finalización determinista tiene un costo. Este tipo de consenso normalmente requiere un conjunto conocido de validadores, mayores costos de comunicación y requisitos más estrictos sobre la tasa de conexión en línea de los nodos y la calidad de la red. Lo que se obtiene es que la confirmación sea definitiva e irreversible; a cambio, se sacrifica la flexibilidad de una expansión sin permiso. Este intercambio debe explicarse con claridad, en lugar de empaquetarlo como “más rápido y más descentralizado”.
El problema que surge es el de la conformación de los validadores. Si el tamaño del conjunto es limitado, el poder se concentra en manos de unos pocos operadores, y tanto la resistencia a la censura de la red como la independencia de la gobernanza deben reevaluarse. Para una cadena que gestione activos regulados, esto quizá no sea necesariamente una desventaja, pero debe ser público y transparente.
Lo que quiero ver es el desempeño bajo presión: ¿alguna vez ha ocurrido una reversión de bloques?, cuando los validadores se desconectan, ¿la red se detiene o sigue avanzando?, ¿cuánto tardó en recuperarse? En un sistema que promete finalización definitiva, el costo de un solo incidente es mucho mayor que el de una cadena ordinaria. La verificación de si la orientación técnica de $DUSK es válida depende de registros reales de funcionamiento, no de tablas de parámetros.
@Dusk_Foundation $DUSK #dusk
La razón es muy práctica. En los sistemas de compensación tradicionales, cuando la entrega se completa, significa la transferencia de propiedad con efectos jurídicos, y sobre ese estado se construyen los dividendos posteriores, las operaciones de embargo y la pignoración. Si el libro contable pudiera reorganizarse debido a una bifurcación, incluso si la probabilidad es extremadamente baja, el área legal y el cumplimiento no lo pueden aceptar. Esto es totalmente distinto al escenario de las transferencias; aquí no aplica la idea de “esperar unas cuantas confirmaciones”.
Buscar una finalización determinista tiene un costo. Este tipo de consenso normalmente requiere un conjunto conocido de validadores, mayores costos de comunicación y requisitos más estrictos sobre la tasa de conexión en línea de los nodos y la calidad de la red. Lo que se obtiene es que la confirmación sea definitiva e irreversible; a cambio, se sacrifica la flexibilidad de una expansión sin permiso. Este intercambio debe explicarse con claridad, en lugar de empaquetarlo como “más rápido y más descentralizado”.
El problema que surge es el de la conformación de los validadores. Si el tamaño del conjunto es limitado, el poder se concentra en manos de unos pocos operadores, y tanto la resistencia a la censura de la red como la independencia de la gobernanza deben reevaluarse. Para una cadena que gestione activos regulados, esto quizá no sea necesariamente una desventaja, pero debe ser público y transparente.
Lo que quiero ver es el desempeño bajo presión: ¿alguna vez ha ocurrido una reversión de bloques?, cuando los validadores se desconectan, ¿la red se detiene o sigue avanzando?, ¿cuánto tardó en recuperarse? En un sistema que promete finalización definitiva, el costo de un solo incidente es mucho mayor que el de una cadena ordinaria. La verificación de si la orientación técnica de $DUSK es válida depende de registros reales de funcionamiento, no de tablas de parámetros.
@Dusk_Foundation $DUSK #dusk
有没有出现过区块回滚
100%
验证者掉线时网络是停止还是继续推进
0%
2 Votos • Votación cerrada