coindesk.com
La actualización planificada de Solana para hacer que los pagos sean definitivos en una fracción de segundo ha alcanzó a su desarrollador público red, proporcionando a los equipos de aplicaciones un lugar para probar antes de que llegue a la blockchain que transporta dinero real.
Llamada Alpenglow, la actualización tiene como objetivo aproximadamente 150 milisegundos para la finalización, el punto en el que una transacción ya no puede ser revertida, en comparación con aproximadamente 12.8 segundos bajo el sistema actual.
Eso podría acortar la espera para que un exchange libere fondos depositados o para que una aplicación de pagos notifique a un comerciante que una venta ha sido completada.
Anza, la empresa que desarrolla el software central de Solana, anunció el cambio en la red de desarrolladores el 25 de septiembre, un día después de que la testnet separada completara su transición. La página de actualizaciones de la Fundación Solana lista a Alpenglow como activo en ambas redes.
Los desarrolladores utilizan la red para desarrolladores, o devnet, para probar aplicaciones con tokens que no tienen valor real. La testnet independiente se utiliza principalmente para realizar pruebas de estrés en el software de la red y en las operaciones de los validadores.
Leer Más: Solana inicia pruebas de una actualización que podría reducir la finalización de 12.8 segundos a 150 milisegundos
Alpenglow cambia la forma en que los validadores, las computadoras que verifican las transacciones, acuerdan los registros de la red. Intercambiarán votos directamente en lugar de registrar esos votos como transacciones dentro de los bloques, los lotes de transacciones añadidos a la cadena de bloques. El acuerdo puede entonces tomar una o dos rondas de votación.
Eliminar esos votos también hará que algunos gráficos de actividad de Solana disminuyan. Los totales de transacciones que incluyen votos de validadores se reducirán incluso si los usuarios realizan la misma cantidad de pagos y operaciones. La Fundación ha solicitado a los proveedores de datos que ajusten sus comparaciones.
Los servicios que construyen historiales de transacciones también necesitan mantener los bloques candidatos en competencia separados hasta que la red seleccione uno. Mezclar sus contenidos podría producir un registro incorrecto.
Las aplicaciones que simplemente envían transacciones y leen saldos de cuenta no requieren migración, según la guía de la Fundación.
