Fuente: CryptoNewsNet
Título original: Los desarrolladores de Neo Core finalizan el alcance de v3.9, avanzan en las pruebas y en el trabajo de diseño de CryptoLib
Original Link: https://cryptonews.net/news/blockchain/32063611/
En la llamada más reciente de Neo Core, los desarrolladores avanzaron en las pruebas para los cambios en las tarifas de ejecución y la lista blanca, refinaron los planes para el soporte BLS compatible con Ethereum en el contrato nativo CryptoLib, y evaluaron un nuevo mecanismo de gobernanza para manejar los fondos bloqueados. La reunión también exploró opciones para asegurar que los candidatos a validadores operen nodos reales, incluyendo diseños basados en staking y slashing.
Asegurando que los candidatos a validadores operen nodos reales
Los desarrolladores abrieron la discusión sobre cómo demostrar que los candidatos al Consejo operan nodos funcionales, un requisito en el camino hacia la reducción de las recompensas de GAS. Se están considerando dos enfoques amplios: un esquema ligero de prueba de trabajo para los candidatos y un modelo de staking y slashing en el que los candidatos bloquean NEO y pueden ser penalizados si no pasan las verificaciones de actividad dentro de un plazo establecido.
Debido a que los nodos de consenso ya exponen la disponibilidad a través del comportamiento de cambio de vista, los nuevos mecanismos están destinados a la verificación de candidatos. Se refinarán más detalles de diseño en el problema correspondiente.
Progreso hacia Neo v3.9.0
Los desarrolladores acordaron que la rama v3.9.0 está casi completa. Se discutió una propuesta para incluir soporte para la firma de mensajes arbitrarios trasladado desde Flamingo. Debido a que la funcionalidad depende de una solicitud de extracción adicional y de una especificación clara para la semántica de los mensajes firmados, puede programarse para una versión posterior si la documentación no se finaliza a tiempo.
Un elemento, NEP-25, no se enviará en v3.9.0. Los cambios planificados en el estándar se espera que retrasen el desarrollo entre uno y dos meses, por lo que los colaboradores acordaron posponerlo para evitar retrasar el lanzamiento.
Prueba de cambios fusionados: tarifas de ejecución y lista blanca
Los cambios en el factor de tarifa de ejecución y el soporte de transacciones gratuitas basadas en listas blancas ya se han fusionado para v3.9.0. Un problema dedicado definirá una lista de verificación de pruebas para estas características antes de que se publiquen los binarios finales.
Se alentó una revisión más amplia de múltiples contribuyentes, particularmente para las solicitudes de extracción que tocan el comportamiento a nivel de protocolo. La intención es reducir el riesgo de comportamiento divergente entre exploradores, billeteras e implementaciones de nodos alternativas una vez que se despliegue la actualización.
Repensando el soporte BLS compatible con Ethereum en CryptoLib
Los desarrolladores también examinaron la propuesta para agregar alias compatibles con Ethereum para BLS12-381 en el contrato nativo de CryptoLib.
Se identificaron dos preocupaciones principales. Los nuevos métodos operan en arreglos de bytes, mientras que la funcionalidad existente de CryptoLib expone puntos BLS a través de interfaces de interoperabilidad con ayudantes de serialización dedicados. La serialización y deserialización repetidas para cada operación son ineficientes e inconsistentes con el diseño actual de la API.
La dirección preferida es alinear el soporte BLS compatible con Ethereum con el estilo de interfaz establecido al agregar métodos de serialización para el formato de Ethereum mientras se ejecutan operaciones en representaciones de puntos BLS internas. La compatibilidad con el formato de serialización de Ethereum es el principal requisito, no una superficie de API reflejada. Los detalles de implementación se refinarán en ambos, el nodo C# y neo-go, para garantizar un comportamiento consistente.
Herramienta de gobernanza para fondos bloqueados
El grupo también revisó un cambio de gobernanza que permitiría al Consejo Neo mover fondos de cuentas bloqueadas después de un período definido, requiriendo 19 de 21 firmas.
El mecanismo está destinado a casos en los que los fondos están congelados en billeteras maliciosas o comprometidas. No está destinado a recuperar activos para usuarios que han perdido claves privadas y no pueden probar la propiedad.
Una votación determinará el período de bloqueo predeterminado, con opciones como seis meses, un año o dos años. Una vez finalizada, se espera que la función proporcione un proceso más claro para manejar direcciones sancionadas.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Los desarrolladores de Neo Core finalizan el alcance de v3.9, avanzan en las pruebas y el trabajo de diseño de CryptoLib
Fuente: CryptoNewsNet Título original: Los desarrolladores de Neo Core finalizan el alcance de v3.9, avanzan en las pruebas y en el trabajo de diseño de CryptoLib Original Link: https://cryptonews.net/news/blockchain/32063611/ En la llamada más reciente de Neo Core, los desarrolladores avanzaron en las pruebas para los cambios en las tarifas de ejecución y la lista blanca, refinaron los planes para el soporte BLS compatible con Ethereum en el contrato nativo CryptoLib, y evaluaron un nuevo mecanismo de gobernanza para manejar los fondos bloqueados. La reunión también exploró opciones para asegurar que los candidatos a validadores operen nodos reales, incluyendo diseños basados en staking y slashing.
Asegurando que los candidatos a validadores operen nodos reales
Los desarrolladores abrieron la discusión sobre cómo demostrar que los candidatos al Consejo operan nodos funcionales, un requisito en el camino hacia la reducción de las recompensas de GAS. Se están considerando dos enfoques amplios: un esquema ligero de prueba de trabajo para los candidatos y un modelo de staking y slashing en el que los candidatos bloquean NEO y pueden ser penalizados si no pasan las verificaciones de actividad dentro de un plazo establecido.
Debido a que los nodos de consenso ya exponen la disponibilidad a través del comportamiento de cambio de vista, los nuevos mecanismos están destinados a la verificación de candidatos. Se refinarán más detalles de diseño en el problema correspondiente.
Progreso hacia Neo v3.9.0
Los desarrolladores acordaron que la rama v3.9.0 está casi completa. Se discutió una propuesta para incluir soporte para la firma de mensajes arbitrarios trasladado desde Flamingo. Debido a que la funcionalidad depende de una solicitud de extracción adicional y de una especificación clara para la semántica de los mensajes firmados, puede programarse para una versión posterior si la documentación no se finaliza a tiempo.
Un elemento, NEP-25, no se enviará en v3.9.0. Los cambios planificados en el estándar se espera que retrasen el desarrollo entre uno y dos meses, por lo que los colaboradores acordaron posponerlo para evitar retrasar el lanzamiento.
Prueba de cambios fusionados: tarifas de ejecución y lista blanca
Los cambios en el factor de tarifa de ejecución y el soporte de transacciones gratuitas basadas en listas blancas ya se han fusionado para v3.9.0. Un problema dedicado definirá una lista de verificación de pruebas para estas características antes de que se publiquen los binarios finales.
Se alentó una revisión más amplia de múltiples contribuyentes, particularmente para las solicitudes de extracción que tocan el comportamiento a nivel de protocolo. La intención es reducir el riesgo de comportamiento divergente entre exploradores, billeteras e implementaciones de nodos alternativas una vez que se despliegue la actualización.
Repensando el soporte BLS compatible con Ethereum en CryptoLib
Los desarrolladores también examinaron la propuesta para agregar alias compatibles con Ethereum para BLS12-381 en el contrato nativo de CryptoLib.
Se identificaron dos preocupaciones principales. Los nuevos métodos operan en arreglos de bytes, mientras que la funcionalidad existente de CryptoLib expone puntos BLS a través de interfaces de interoperabilidad con ayudantes de serialización dedicados. La serialización y deserialización repetidas para cada operación son ineficientes e inconsistentes con el diseño actual de la API.
La dirección preferida es alinear el soporte BLS compatible con Ethereum con el estilo de interfaz establecido al agregar métodos de serialización para el formato de Ethereum mientras se ejecutan operaciones en representaciones de puntos BLS internas. La compatibilidad con el formato de serialización de Ethereum es el principal requisito, no una superficie de API reflejada. Los detalles de implementación se refinarán en ambos, el nodo C# y neo-go, para garantizar un comportamiento consistente.
Herramienta de gobernanza para fondos bloqueados
El grupo también revisó un cambio de gobernanza que permitiría al Consejo Neo mover fondos de cuentas bloqueadas después de un período definido, requiriendo 19 de 21 firmas.
El mecanismo está destinado a casos en los que los fondos están congelados en billeteras maliciosas o comprometidas. No está destinado a recuperar activos para usuarios que han perdido claves privadas y no pueden probar la propiedad.
Una votación determinará el período de bloqueo predeterminado, con opciones como seis meses, un año o dos años. Una vez finalizada, se espera que la función proporcione un proceso más claro para manejar direcciones sancionadas.