一只瓢虫

Lejos en el horizonte, pero compartiendo este momento: en BSC, celebramos el Festival del Medio Otoño con el mundo
Este año, es el 4.º Festival del Medio Otoño que paso junto con las criptomonedas. Cuando compré BNB por primera vez, creía que las criptomonedas eran solo subidas y bajadas en una pantalla; luego, al entrar en Binance y cruzar BSC, descubrí que se parece más a una red que no tiene husos horarios. En el Medio Otoño se celebra la reunión, y en la cadena también hay reencuentro: conectar a personas de diferentes continentes, diferentes idiomas y distintos husos horarios dentro del mismo mercado.
Antes, el trading tenía “diferencia horaria”: Nueva York cerraba mientras Tokio todavía no despertaba, y los inversores asiáticos a menudo tenían que trasnochar. Hoy, Binance y BNB Chain hacen que las 7×24 ya no sea solo un eslogan. A las tres de la madrugada, termino una transferencia en BSC: el Gas lo pago con BNB y la confirmación tarda solo unos segundos. Al mismo tiempo, en el otro extremo del planeta, un compañero mira los gráficos en Binance, participa en Launchpool y conversa sobre el ecosistema. La luna me ilumina a mí, y también a él; la cadena de bloques es como una posta bajo la luz de la luna, que reúne a participantes de diferentes regiones en un mismo flujo.
Sueño con el futuro: los mercados globales ya no serán islas separadas; las acciones, el oro, los bonos y los RWA podrán negociarse en la cadena 24/7. Binance es ese “muelle financiero global” que nunca cierra, y BSC es el puente que conecta activos y usuarios. Operar sin desfase horario no es solo que las velas no se detengan, sino la oportunidad de que la gente común participe también de manera conjunta en las finanzas globales. No importa en qué huso horario estés, al abrir Binance y conectar con BSC, puedes sincronizarte con el mundo.
Lejos en el horizonte, pero compartiendo este momento. Este 4.º Festival del Medio Otoño del año, al mirar hacia arriba en la cadena, no solo veo la luna, sino también incontables nodos que brillan al mismo tiempo. Ojalá en el próximo Medio Otoño sigamos brindando en BNB Chain y que, en Binance, seamos testigos de cómo el mercado global late al unísono.
#币安中秋故事

bDespués de la apertura de la pignoración de acciones, ¿cómo se puede lograr mejor «activar las posiciones» mientras se controla el riesgo? Por ejemplo, si con el capital prestado se vuelve a invertir en otros activos, ¿hay recomendaciones de posicionamiento o coberturas que sean más seguras?

Vaya, 333166 HYPE$HYPE

¡Guau! Compraron 45 millones de dólares por $PONS y $CASHCAT

BTC acaba de caer por debajo de 78.000 dólares, pero en las últimas 24 horas sigue subiendo; esta tendencia de verdad deja a cualquiera sin entender nada 😂$BTC

Vaya, el BTC$BTC ha caído por debajo de los 78.000 dólares

¡Vaya, 10.400.000 de dólares para comprar 20.310.000 de MEME$MEME

Unas ballenas enormes sacaron 1.1 millones de USDT de Binance y, al voltear, compraron con un precio promedio de 0.1155 dólares 9.53 millones de $BTC en modo “$bull”, ¿es que van a levantar directamente el precio de las “$bull”?$USDC

Guau, 1100 mil, $USDC

¡Guau, ¡un billón de dólares! $SOL

Cada ronda de consenso debe incluir un nuevo bloque. Pero el whitepaper dice que esta ronda no se completa en un solo paso, sino en múltiples iteraciones, y que cada iteración se divide en tres fases. La sección 3.2 del whitepaper llama a estas tres fases Proposal, Validation y Ratification.

Primera fase: Proposal. El algoritmo DS selecciona aleatoriamente un provisioner como productor del bloque, que se encarga de generar un bloque candidato y difundirlo por toda la red. Si el bloque candidato no se produce o no se recibe dentro del tiempo de espera estipulado, esta fase devuelve NIL e inmediatamente pasa a la siguiente; pero como no hay un bloque candidato en la mano, ¿qué se vota en las votaciones posteriores? La respuesta es: no se emiten votos vacíos, sino que se vota NoCandidate, lo que significa "no hay ningún bloque candidato verificable". $DUSK

Segunda fase: Validation. El algoritmo DS selecciona aleatoriamente un conjunto de comités de votación para verificar el bloque candidato de la fase anterior. Si el bloque candidato es válido, se vota Valid; si no es válido, se vota Invalid; y si no hay bloque candidato, se vota NoCandidate. El comité de votación necesita una mayoría absoluta de 2/3 para alcanzar quorum. Si el quorum aún no se alcanza cuando vence el tiempo, se devuelve NoQuorum. El resultado de esta fase es un ValidationResult, que incluye el tipo de voto que alcanzó el quorum y las firmas agregadas de todos los votantes. @Dusk

Tercera fase: Ratification. Se selecciona otro comité nuevo de votación para confirmar el resultado de Validation. Si en el paso anterior se alcanzó el quorum de Valid, lo confirman; si el paso anterior fue NoQuorum o falló, votan NoQuorum. Esta fase asegura que el resultado de la verificación no lo decida únicamente una minoría, sino que sea reconocido por un mayor número de provisioners.

Si la salida de Ratification es Success, el bloque candidato se acepta formalmente como el nuevo bloque y la ronda termina. Si la salida es Fail u unknown, se entra en la siguiente iteración: se vuelve a seleccionar el productor del bloque y se vuelve a votar. El whitepaper indica que el número máximo de iteraciones lo determina un parámetro global; el valor actual es 50. Si las iteraciones fallan consecutivamente 16 veces, el protocolo entra en modo de emergencia (ángulo 10).

La lógica central del diseño de tres fases es el equilibrio: el productor del bloque solo puede generar bloques candidatos, pero no puede votar; el comité de verificación solo puede verificar, pero no puede confirmar; y el comité de confirmación solo puede confirmar el resultado de la verificación, pero no puede volver a verificar. Ningún rol puede decidir por sí solo el destino de un bloque. #dusk

Cuando la red Dusk se inicia, no basta con la máquina virtual Piecrust; también debe desplegar un conjunto de contratos génesis para gestionar las operaciones más básicas. La sección 6.2 del libro blanco los llama "genesis contracts": son contratos inteligentes especiales que se despliegan durante la inicialización de la red y se encargan de funciones fundamentales como la validación de transacciones, el mecanismo de staking y la distribución inicial de tokens. El libro blanco destaca dos de ellos.

El primero es el transfer contract (contrato de transferencia). Gestiona todas las transferencias de DUSK y $DUSK también maneja la deducción de las comisiones de gas. Si una transacción incluye el despliegue o la llamada de un contrato inteligente, el transfer contract también se encarga de procesarla: verifica si la transacción cumple con las reglas de Moonlight o Phoenix y luego deduce la comisión de gas correspondiente del saldo del remitente. El libro blanco dice que es el "punto de entrada a la cadena de bloques Dusk"; todas las transacciones, en última instancia, deben pasar por él.

El segundo es el stake contract (contrato de staking). Gestiona todo el ciclo de vida del staking: verifica si la cantidad depositada por el usuario alcanza el umbral mínimo de staking, bloquea los tokens y registra al usuario como provisioner. Cuanto más DUSK se pone en staking, mayor es la probabilidad de ser seleccionado por el algoritmo DS para participar en el consenso. El contrato también procesa las solicitudes de desstaking: después de que termine el período de bloqueo, el usuario puede recuperar los tokens, al mismo tiempo que garantiza que la distribución de recompensas y la deducción de penalizaciones se ejecuten correctamente. El umbral de 1000 DUSK mencionado en el ángulo 1 y las recompensas y penalizaciones mencionadas en el ángulo 9 se implementan concretamente gracias a este contrato. @Dusk

La sección 6.3 añade además dos "otros contratos". Uno es el license contract (contrato de licencia), que gestiona la emisión y verificación de licencias en la red basándose en el protocolo Citadel, rastreando la propiedad, validez y fecha de expiración de cada licencia, y procesando revocaciones o renovaciones. El otro es Zedger contracts, que instancia contratos inteligentes independientes para cada tipo de activo de valor, proporcionando funciones como acuñación, destrucción, reparto de dividendos y transferencia forzosa, y constituye la implementación concreta del protocolo Zedger mencionado en el ángulo 7.

La división de funciones de los cuatro contratos es muy clara: el transfer contract gestiona la circulación, el stake contract la participación en el consenso, el license contract los permisos y los Zedger contracts los activos. Pero esto también significa que las funciones centrales de Dusk dependen en gran medida de la corrección de estos cuatro contratos: si cualquiera de ellos tiene un bug, el impacto no se limitará a una sola aplicación, sino que afectará a las operaciones básicas de toda la red. #dusk

El “Trabajo relacionado” de la Sección 1.1 del Libro Blanco en realidad solo hizo una cosa: decirle al lector que Dusk no es cualquiera.

El libro blanco divide las blockchains existentes en tres categorías. La primera son las plataformas de contratos inteligentes de uso general, como Ethereum y Cardano. Su problema es que la transparencia hace que los datos financieros sensibles no tengan dónde esconderse; incluso con soluciones de capa 2 como zk-rollup, solo son parches, no un diseño nativo. La segunda son las blockchains de privacidad, como Zcash y Monero. En cuanto a la privacidad individual, las llevan al extremo, pero carecen de marcos de cumplimiento, de auditabilidad y de capacidades de contratos inteligentes orientados a transacciones confidenciales. La tercera es la que Dusk quiere hacer: ninguna de las dos anteriores.

Lo que Ethereum puede hacer, Dusk@Dusk no lo hace: no busca abarcar todo el DeFi de propósito general, sino enfocarse en escenarios financieros regulados. Lo que Zcash y Monero pueden hacer, Dusk también lo hace: utiliza pruebas ZK para lograr privacidad, pero sobre esa base añade interfaces de cumplimiento y capacidades de auditoría. El libro blanco lo deja muy claro: “Zcash y Monero carecen de las funciones necesarias para la integración con la industria de las finanzas reguladas”, incluyendo marcos regulatorios, auditabilidad y capacidades de contratos inteligentes para apoyar transacciones confidenciales.$DUSK

Esto no es una frase que diga “Dusk es mejor que todas ellas”, sino una que dice “Dusk eligió un carril diferente”. Eligió una ruta más estrecha: una blockchain de privacidad con cumplimiento para instituciones financieras tradicionales, en lugar de una blockchain de privacidad para todos. El camino se vuelve más estrecho: significa que el público objetivo está más definido, pero también significa que si las instituciones financieras tradicionales no lo aceptan, esa posición no tiene sentido.#dusk

Cuando leí hasta el capítulo 6, noté una elección clave: el entorno de ejecución de contratos inteligentes de Dusk es Piecrust, basado en WebAssembly, y no es compatible con EVM. En 2024 seguir eligiendo la incompatibilidad con EVM es una decisión que necesita explicación.$DUSK

El whitepaper dice que Piecrust es una implementación de una máquina virtual WASM, escrita en Rust. Su núcleo son dos componentes: el crate piecrust, que se encarga de la propia máquina virtual; y piecrust-uplink, un kit de herramientas de desarrollo que proporciona un toolchain para compilar, desplegar y probar contratos. El whitepaper subraya que su objetivo de diseño es ser compacto, seguro, modular y ligero.

Pero lo que de verdad me interesa es el diseño de las host functions. Dusk@Dusk traslada trabajos pesados como la verificación de pruebas ZK, la verificación de firmas y el cálculo de hashes desde la máquina virtual al entorno anfitrión. El whitepaper enumera host functions específicas: la función hash admite Blake2b y Poseidon como dos algoritmos de hash; verify_plonk y verify_groth16_bn254 verifican, respectivamente, pruebas ZK de PlonK y Groth16; verify_schnorr y verify_bls verifican firmas, con soporte tanto para firmas individuales como para multisig. Todo esto se ejecuta en el entorno nativo, no dentro del sandbox WASM.#dusk

¿Por qué hacer esto? El whitepaper cita datos de investigación que indican que ejecutar aplicaciones complejas en WASM es entre un 45% y un 255% más lento que ejecutarlas en código nativo. Para una cadena que usa intensamente pruebas ZK, esta diferencia de rendimiento es crítica. Si cada transacción tuviera que verificar una prueba PlonK en WASM, solo ese costo volvería inaceptable la latencia de las transacciones. Al trasladar la verificación al entorno anfitrión, se sortea el obstáculo.

Pero lo que hace Dusk también tiene un costo. Ser incompatible con EVM significa que los contratos inteligentes existentes en Ethereum no se pueden migrar directamente a Dusk; los desarrolladores necesitan aprender de nuevo el toolchain de desarrollo en WASM. La compatibilidad con EVM es una “carta de seguridad” en la industria, porque ya hay muchos desarrolladores, herramientas y bases de código. Dusk renuncia a esa carta, lo que indica que tiene una orientación clara hacia su base objetivo: desarrolladores institucionales que trabajan con valores y activos del mundo real.

El toolchain que proporciona piecrust-uplink, incluido compilar contratos en módulos WASM, ejecutarlos en un entorno controlado, y verificar su corrección y seguridad, parece estar compensando la debilidad en la experiencia de desarrollo. Pero si esas herramientas son realmente fáciles de usar, el whitepaper no ofrece una respuesta; eso solo se puede confirmar cuando los desarrolladores las usan en la práctica.

我读到第5节的时候，发现Dusk在能源效率上做了很多功课，而且给了具体数据，这让我觉得他们确实认真考虑过这个问题。

先看共识层面。白皮书引用了以太坊转PoS后的数据，能耗降低了99.95%以上。但SA共识不只是PoS，它还是委员会制的PoS。白皮书说，确定性分配让区块生成和验证都不需要密集计算，因为谁干活是提前选好的，不是靠算力竞争。委员会只由被选中的那组provisioner参与，而不是全网一起验证，所以整体计算量更小。$DUSK

网络层面，Kadcast的数据更有意思。白皮书说，相比Gossip协议，Kadcast能减少25%到50%的带宽消耗。这不是猜的，是引用了研究数据。而且Kadcast还能降低10%到30%的孤儿块率——就是那些被广播出去但最终没被接受的块。在PoS网络里，少一个孤儿块，就意味着少了一轮白费的投票和验证工作。

加密操作层面，Dusk把ZK证明验证、签名验证、哈希计算这些重活从WASM虚拟机里搬到了宿主环境，用host functions来跑。白皮书引用了研究数据，说在WASM里执行复杂应用比原生代码慢45%到255%。把这个额外开销省掉，对一条大量使用ZK证明的链来说，省下来的计算量是相当可观的。#dusk

不过白皮书也诚实地说，这些能耗节省的具体数字还没有被量化。Kadcast的带宽节省数据来自其他网络，不是Dusk主网实测。这让我觉得他们写白皮书的时候，态度是严谨的，没有为了好看而编数据。

但反过来想，如果Dusk@Dusk 的SA共识真的把验证者数量降到很小的规模，那能耗确实会比以太坊的PoS还要低。以太坊PoS虽然不挖矿了，但全网有几十万验证者，每个人都要跑全节点验证。如果Dusk的验证工作由小规模的委员会来做，那单次验证的能耗确实会少很多。这个逻辑在理论上是成立的，但实际效果，还得等主网上线后拿数据说话。

Cuando leí el libro blanco y llegué al protocolo Zedger, tuve esa sensación de «al fin llegó». Después de haber preparado tanto antes, desde la privacidad hasta el cumplimiento normativo y el modelo de doble transacción, Zedger es el punto culminante de todas esas ideas técnicas. $DUSK

El libro blanco dice que Zedger es un protocolo para gestionar valores y activos del mundo real, que admite la acuñación, la destrucción, acciones corporativas como el pago de dividendos e incluso la transferencia forzosa. Estas funciones, por sí solas, muestran que sus usuarios objetivo no son los minoristas, sino las instituciones que emiten valores.

Me fijé especialmente en la función de «transferencia forzosa». En Ethereum, tus activos son tuyos y nadie puede moverlos. Pero en los mercados financieros del mundo real, un tribunal puede congelar activos, un liquidador puede forzar transferencias y los reguladores pueden exigir la recuperación. Zedger incorpora esta capacidad, lo que demuestra que su comprensión del cumplimiento regulatorio no se queda en eslóganes, sino que realmente está diseñada para las necesidades de las instituciones. @Dusk

Pero aquí hay un equilibrio muy sutil. Si la función de transferencia forzosa se usa de forma indebida, entonces no es cumplimiento, es centralización. El libro blanco afirma que Zedger utiliza pruebas de ZK y capacidades de auditoría para garantizar la legitimidad, al mismo tiempo que protege la privacidad del usuario. Yo lo que entiendo es que cada transferencia forzosa debe ir acompañada de una prueba criptográfica de cumplimiento, que demuestre que esa operación es legal, pero sin necesidad de revelar los detalles de la transacción.

Sin embargo, el libro blanco describe a Zedger de manera bastante general y no detalla quién tiene la autoridad para ejecutar transferencias forzosas, cómo se distribuyen los permisos ni cómo se evita el abuso. Si la autoridad la mantiene unilateralmente el emisor, entonces el sistema, en esencia, es centralizado. Si la autoridad debe activarse mediante gobernanza on-chain o mediante multisig, entonces la seguridad y el grado de descentralización serían mucho más altos.

Me inclino a pensar que la filosofía de diseño de Zedger es correcta: para RWA y valores aporta un marco técnico claro. Pero su nivel real de descentralización depende de cómo se implemente el control de permisos. El libro blanco deja aquí un espacio que vale la pena explorar y cuestionar. #dusk

Cuando leí esta parte sobre el consenso de SA, mi primera reacción fue buscar sus parámetros de finalización. El whitepaper dice "finalidad en segundos", pero no especifica exactamente cuántos segundos. Esa ambigüedad me incomodó un poco, pero también me hizo querer entender mejor la lógica que hay detrás.

Primero, hagamos una comparación. La finalización de Bitcoin $DUSK se basa en la probabilidad: con 6 confirmaciones de bloques, aproximadamente 1 hora; cuanto más esperas, más seguro estás de que la transacción no se revertirá. La finalización en Ethereum PoS, basada en el protocolo Casper, requiere dos epochs, aproximadamente 12,8 minutos. Dusk dice que solo toma unos segundos, ¿por qué?

El punto clave está en su mecanismo de asignación determinista. El whitepaper afirma que, antes de que comience cada ronda, el algoritmo DS ya seleccionó de antemano quién será el productor del bloque y quién integrará el comité de votación. Ese "conocimiento previo" significa que los votantes ya están listos antes de que se genere el bloque: no hace falta reclutar a nadie sobre la marcha, ni hace falta difundir por toda la red para buscar consenso. Los costos de comunicación se reducen drásticamente.

Desglosé el flujo. Cada ronda incluye múltiples iteraciones, y cada iteración tiene tres etapas: propuesta, votación y confirmación. El comité de votación solo lo componen el grupo seleccionado de validadores, no participa toda la red. El número de nodos que participa en la votación se controla dentro de un rango relativamente pequeño, por lo que el volumen de comunicación del proceso de votación es muy bajo; con intercambios de información de apenas unos cuantos ciclos se completa @Dusk

Pero aquí hay algo que no llego a entender. El whitepaper menciona el término "finalidad en movimiento" (rolling finality), pero no desarrolla el mecanismo en detalle. Mi interpretación es que puede referirse a que la finalidad no queda fijada de una vez, sino que, a medida que se generan continuamente nuevos bloques, la probabilidad de que el bloque anterior sea final va aumentando. Si fuera así, entonces los "segundos" podrían referirse a la confirmación de la primera capa, no a una finalización irreversible. #dusk

Además, noté que el whitepaper no proporciona una cifra precisa de segundos. Tanto 3 como 9 segundos se llaman "segundos", pero para un escenario financiero, la diferencia es enorme. Por ahora no puedo encontrar la respuesta a partir del whitepaper; probablemente haya que esperar a los datos de pruebas reales tras el lanzamiento de la red principal.

Mientras leía el libro blanco, esta pregunta no dejaba de dar vueltas en mi cabeza. El mayor relato de Dusk es que quiero tenerlo todo: privacidad y cumplimiento, pero la experiencia histórica me dice que ese tipo de promesas normalmente no satisfacen a nadie. #dusk

Primero, veamos el ejemplo contrario. Zcash y Monero llevaron la privacidad al extremo, pero los reguladores no lo aceptaron: las bolsas las retiraron y la liquidez se contrajo. Ethereum y Bitcoin no tienen problemas con el cumplimiento, pero todas las transacciones son transparentes; si una institución hace una transacción grande, el contrapartista lo ve todo con total claridad. Dusk dice que encontró un tercer camino, y al principio dudé. @Dusk

La propuesta del libro blanco es un modelo de doble transacción y el protocolo Zedger. Moonlight se usa para escenarios de cumplimiento, Phoenix para escenarios de privacidad, y Zedger se encarga de que los contratos inteligentes se ejecuten en estado confidencial, manteniendo al mismo tiempo la auditabilidad. En teoría, esta arquitectura podría funcionar.

Pero después de terminar la lectura encontré un vacío clave. El libro blanco dice que las autoridades regulatorias pueden acceder a los datos necesarios, pero no explica cómo se accede, mediante qué mecanismos se autoriza, quién custodia las claves ni cómo se revocan los permisos. En un sistema de privacidad auditable, lo más difícil no es lograr que el regulador vea los datos, sino garantizar que solo los vea la gente autorizada y solo durante los periodos de tiempo en que esté permitido.

Lo intenté razonar desde ese ángulo. Si Dusk adoptara un sistema de pruebas similar a zk-SNARK, y las autoridades tuvieran una clave de auditoría específica, entonces $DUSK podría verificar el cumplimiento de la transacción sin exponer la privacidad del usuario. En ese caso, el esquema tendría sentido. Pero si se abusa de los privilegios regulatorios o si se filtra la clave, se derrumba el edificio entero de la protección de la privacidad.

Así que mi conclusión es que la coexistencia de privacidad y cumplimiento, en principio, se puede sostener y, a nivel de ingeniería, también es posible. Sin embargo, el resultado real depende por completo de los detalles del diseño del mecanismo de control de permisos. Y como el libro blanco todavía no proporciona esos detalles, solo puedo esperar a que salgan más documentos técnicos para evaluarlo. La respuesta a esta pregunta no está en el libro blanco, está en el código de la mainnet.

我读Kadcast这部分的时候，脑子里一直在对比以太坊的gossip协议。gossip的逻辑很简单，你收到一条消息，转发给你知道的所有邻居，邻居再转发给他们的邻居，直到全网都收到。但这里有一个问题，随着节点数增长，消息重复转发量是指数级上升的。

Kadcast的做法不一样。它基于Kademlia的DHT，把节点按XOR距离分层。每个节点不是向所有邻居转发，而是只向递增XOR距离上的选定节点转发。这个机制我读了两遍才理解它的巧妙之处——它形成的是一个级联效应，而不是泛洪。

举个例子，节点A发出一条消息，它只转发给距离它最近的几个节点，这些节点再转发给更远的节点。每一层转发的目标节点数量是受控的，不是无限制扩散。白皮书里说，这大幅减少了网络传播所需的总体传输次数。

那这个设计和金融场景$DUSK 有什么关系。我的理解是，金融场景对两个东西特别敏感，一个是延迟，一个是带宽。如果一条交易广播需要十几秒甚至几十秒才能传遍全网，那秒级最终性就没有意义了。Kadcast通过树状结构让消息在最少的中继次数内到达所有节点，传播时间被压缩到极致。

还有一个点我一开始没注意到，白皮书提到Kadcast自然混淆了消息的起源点。因为节点只和选定的对等节点通信，不向全网广播，攻击者很难追踪一条交易是从哪个节点发出来的。这对Dusk@Dusk 的隐私叙事来说，是一个额外的加分项。

不过我还是有一个疑问。白皮书对比了gossip和Kadcast，但只给了定性描述，没有具体的带宽节省数据。省了多少，是省了30%还是90%。没有这个数据，我其实很难判断它的效率优势到底有多大。也许这个量级需要在主网上线后用实际网络数据来回答。#dusk

Mi primera reacción al leer el consenso de SA fue: ¿cómo se obtiene el número 1000 DUSK? El whitepaper solo da el resultado, no el proceso de deducción. Así que seguí sus parámetros para reconstruirlo.

Establece un epoch de 2160 bloques. Según la velocidad de producción actual de Dusk, aproximadamente 6 horas conforman un epoch. Luego da una fórmula de periodo de madurez: M = 2 × epoch - (height mod epoch). Es decir, si haces staking de una cantidad de DUSK, tienes que esperar desde casi medio epoch hasta un epoch completo para que realmente empiece tu participación.

Hay algo interesante en este diseño: alinea el tiempo de activación de todos los nuevos stakes con el límite del epoch. No se activa “en cuanto entras”, sino que todos se activan colectivamente en el mismo punto. Supongo que el objetivo es que el sorteo determinista del algoritmo DS tenga una instantánea estable del pool de staking. Si entran y se activan en cualquier momento, entonces el conjunto de candidatos provisioner de cada bloque cambia; así la asignación determinista se vuelve difícil de implementar $DUSK

¿Y el 1000 DUSK en sí? Yo calculé que, si el umbral se fija en 100, la cantidad de provisioners se dispararía. Con 64 slots compitiendo más intensamente en cada epoch, pero la cantidad de staking por nodo sería demasiado baja; la seguridad de la red podría incluso diluirse. Si se fija en 10000, entonces el público minorista básicamente no podría entrar: los provisioners se reducirían a unos pocos nodos grandes, y la descentralización se vería afectada en consecuencia. @Dusk

El número 1000 queda en medio. Revisé los parámetros de otras cadenas PoS: el umbral de Dusk no es particularmente alto, pero tampoco es bajo. Es como si dijera: no quiero que ejecutes un nodo con solo una propina cualquiera, pero tampoco quiero que necesariamente tengas que ser un “ballena” para participar.

Sin embargo, todavía tengo una pregunta que no termino de entender. El whitepaper no especifica el rango objetivo del número total de provisioners, ni tampoco qué proporción de intensidad de competencia entre los 64 slots sería la óptima. Sin esos datos, en realidad no puedo determinar si 1000 es adecuado. Tal vez su razonabilidad solo pueda verificarse con datos reales después del lanzamiento en la red principal. #dusk