Lisk Betanet v4 lanzado con un nuevo modelo de tarifas y límites de transacción
Todos los objetivos de la fase de Economía y Consenso se han implementado con éxito en Lisk SDK 4.0.0 y, por lo tanto, Lisk Core 3.0.0-beta.1 ha sido lanzado. Esto viene con una multitud de nuevas características en el protocolo y varias mejoras a nivel de código. Betanet v4 reemplazará al Betanet v3 actual, que funcionaba de manera estable desde febrero de 2020. Por lo tanto, a partir de ahora, betanet.lisk.io se ejecutará en Lisk Core 3.0.0-beta.1.
Nuevas funciones de protocolo
Economía de la red
LIP0002 : cambio al límite de tamaño de bloque basado en bytes
Establecimos un tamaño de bloque máximo de 15 KB (kilobytes), reemplazando el máximo actual de 25 transacciones por bloque. Este tamaño mantendrá el crecimiento anual de la cadena de bloques por debajo de 50 GB, incluso cuando los bloques estén siempre a plena capacidad y los delegados activos no pierdan ningún bloque. Una cadena de bloques creada con Lisk SDK 4.0.0 puede incluir más de 100 transacciones de transferencia de saldo en un bloque y procesar hasta alrededor de 1,000,000 de transacciones en un día.
LIP0026 : establezca la validez de bloque aplicando transacciones secuencialmente
Cambiamos la regla para ordenar transacciones dentro de un bloque. Anteriormente, las transacciones se ordenaban automáticamente de acuerdo con un conjunto de reglas complejas. Después de esta mejora, la orden de transacción puede ser elegida libremente por el productor del bloque, y un bloque es válido si cada transacción es válida contra el estado transitorio que la conduce.
LIP0013 : Reemplazo del sistema de tarifas estáticas por sistemas de tarifas dinámicas
El nuevo sistema de tarifas dinámicas permite a los usuarios elegir libremente una tarifa adecuada para su transacción siempre que esta tarifa sea igual a la tarifa mínima requerida para el tipo y tamaño de la transacción. Este sistema reemplaza las reglas de tarifas fijas anteriores, lo que resulta en una tarifa significativamente más baja para todos los tipos de transacciones, excepto los registros de delegados. Una parte de la tarifa de transacción irá al delegado que forja el bloque, incluida la transacción, mientras que la otra parte de la tarifa de transacción se quema.
LIP0016 : Implementar el algoritmo de estimación de tarifas para el sistema de tarifas dinámicas
Introducimos un algoritmo de estimación de tarifas basado en una media móvil exponencial (EMA). La tarifa sugerida depende del uso de la red y la urgencia de la transacción. El algoritmo se implementa en un nodo de la red Lisk y la billetera consulta su salida para obtener la estimación de la tarifa de transacción para el usuario.
LIP0025 : introducir requisitos de saldo mínimo para cuentas
Introducimos una nueva regla para la cual las cuentas también deberán mantener un saldo mínimo de 0.05 LSK. Esto evita el envío de spam a la base de datos al crear muchas cuentas casi sin saldo (cuentas de polvo), abusando de las tarifas de transacción muy reducidas introducidas con el sistema de tarifas dinámicas.
LIP0017 : Flexibilice las cuentas con varias firmas, evite el spam y evite la mutabilidad de las firmas
El sistema de múltiples firmas se ha mejorado y mejorado. La primera mejora es que solo las transacciones válidas de cuentas de múltiples firmas, es decir, transacciones con todas las firmas requeridas, son aceptadas y permitidas para ser reenviadas por los nodos. Esto evita el spam de la red y el grupo de transacciones. A continuación, la configuración de las reglas de la cuenta se vuelve más flexible. Por ejemplo, ahora es posible crear m -out -of- n cuentas de múltiples firmas , requiriendo m firmas de un conjunto de nclaves públicas. Además, el límite superior del número de claves participantes se incrementa a 64 y el conjunto de firmas de una transacción incluida en un bloque se vuelve inmutable. Por último, eliminamos el concepto de segunda firma y convertimos todas las cuentas con segundas firmas en cuentas con múltiples firmas.
LIP0015 : Garantice la invalidación de transacciones utilizando nonces en lugar de marcas de tiempo
Reemplazamos la propiedad de marca de tiempo de una transacción por un nonce ordenado. Esto permite invalidar una transacción pendiente emitiendo una nueva transacción reutilizando el mismo nonce, pero con una tarifa más alta (por lo tanto, con una mayor probabilidad de ser incluido en un bloque primero). Además, un mecanismo de invalidación asegura que una transacción no se incluya en una etapa posterior, por ejemplo, en el caso de que un usuario transmita una transacción a la red sin recibir retroalimentación.
Consenso de la red
LIP0003 : Orden uniforme de la lista de delegados
Cambiamos el orden de los delegados que forjan espacios en una ronda. El espacio de delegado se calcula aplicando un hash a la identificación única de cada delegado junto con una identificación única para la ronda, lo que da como resultado una mezcla uniforme de la lista de delegados activos. Los delegados se ordenarán de forma única de acuerdo con estos valores hash.
LIP0023 : introducir períodos de bloqueo de votos y una nueva definición de peso
Se ha mejorado el sistema de votación para seleccionar los productores de bloques. Los usuarios ahora tienen que bloquear los tokens que quieren usar para votar, y un token LSK solo se puede usar para votar por un delegado simultáneamente. Además, el cálculo del peso de los delegados ahora tiene en cuenta cuántos tokens han bloqueado los delegados para votar por sí mismos. Al requerir que el peso de los delegados debe contener al menos el 10% de los votos propios, nos aseguramos de que los delegados tengan una cantidad significativa de tokens en juego, lo que aumenta aún más la seguridad de la red.
LIP0022 : esquema basado en Randao de usuario para incluir delegados en espera y reordenar la lista de delegados
Con esta mejora, la lista de delegados de forja incluirá dos delegados de reserva de cada ronda. La longitud de la ronda se extiende de 101 a 103 bloques y los 2 respacios de bloques adicionales se asignan a los delegados en espera mediante un algoritmo de selección aleatorio proporcional al peso del delegado, lo que garantiza tanto la imprevisibilidad como la equidad del proceso.
Este cambio está diseñado para incentivar un mayor número de nodos en línea en la red Lisk.
LIP0024 : castigar las violaciones de BFT
Introducimos una nueva transacción de "Prueba de mala conducta" para castigar las violaciones del protocolo de consenso Lisk BFT, como forjar varios bloques en conflicto en el mismo intervalo de tiempo. Esta transacción contiene la información necesaria para probar la infracción. El delegado que se porta mal es castigado con su peso en 0 durante 3 meses. Además, las fichas utilizadas para votar al delegado que se porta mal se bloquean por un período de 1 mes, para dar a los votantes un fuerte incentivo económico para elegir a sus delegados con cuidado. Los delegados que han sido castigados 5 veces están prohibidos y ya no pueden forjar bloques.
Futuras mejoras
Actualización para utilizar hilo para la gestión de monorepo
Cabe señalar que, aunque lerna es competente en la gestión de monorepo, se encontraron una multitud de problemas con respecto al arranque lento, la auditoría de paquetes incorrecta y los conflictos de bloqueo de paquetes. Por lo tanto, ahora se utilizará hilo para la gestión de monrepo.
Recursos para Betanet v4
En el Betanet v3 anterior, Lisk Desktop estaba listo para admitirlo, sin embargo, esta vez tuvimos que comprometernos a lanzar Betanet sin un producto de interfaz de usuario correspondiente para acelerar el lanzamiento del Lisk Core 3.0.0 final a Mainnet. Por lo tanto, el acceso ahora será a través de Lisk Commander . Una versión compatible de Lisk Desktop se lanzará después de Betanet v5 a principios del próximo año.
El Lisk grifo se actualiza a 3.0.0-beta.1 para apoyar los cambios Betanet. Además, la documentación Lisk SDK y la documentación Lisk Core se han actualizado para reflejar todos los cambios nuevos realizados.
Problemas conocidos
Ya hemos identificado algunos problemas en Lisk SDK 4.0.0 que ahora se han corregido en Lisk SDK 5.0.0. Para evitar la duplicación de comentarios sobre las pruebas de nuestra comunidad, proporcionamos una lista de problemas conocidos a continuación:
- Ocurrió un error durante la sincronización # 5742
El sincronizador fue diseñado para no activarse varias veces; sin embargo, se activó, lo que generó el error.
- Error al restaurar bloques de la tabla temporal de bloques al iniciar un nodo nuevo # 5807
Cuando existen bloques guardados temporalmente y luego se inicia un nodo, debe optar por restaurar los bloques o eliminarlos, sin embargo, se produjo este error.
- El sincronizador puede ejecutarse dos veces al mismo tiempo # 5828
El sincronizador fue diseñado para no ejecutarse varias veces simultáneamente, sin embargo, intenta seguir funcionando.
- Las propiedades de carga útil no utilizadas pueden aumentar el análisis general de los mensajes . # 5212
Agregar propiedades adicionales en la comunicación P2P aumenta el tiempo para analizar el objeto, lo que conduce a usos de recursos innecesarios.
El camino por delante con Lisk SDK 5.0.0
El desarrollo y las pruebas alfa internas para Lisk SDK 5.0.0 se han completado con éxito. En la actualidad, la auditoría de seguridad externa para Lisk SDK 5.0.0 está en curso. Mientras tanto, estamos trabajando simultáneamente en los objetivos de lanzamiento de Lisk SDK 5.1.0 .
Lisk tiene la misión de permitirle crear aplicaciones blockchain descentralizadas, eficientes y transparentes.
Fuente: blog de Lisk
