Preparación y Codificación de la Mainnet en Berlín

La semana pasada nuestro equipo central, que generalmente está esparcido por Europa, se reunió durante la Berlin Blockchain Week. Se realizaron muchas discusiones geniales, se llevaron a cabo sesiones de planificación y se realizó una codificación muy productiva.

Mainnet, Mainnet, Mainnet…

Como se puede ver en æternity Pivotal Tracker y VM Pivotal Tracker, hemos reducido el alcance de nuestro Mainnet Release Candidate, que es rastreado por las etiquetas Mainnet RC æternity y Mainnet RC VM.

Nuestro equipo se quedó en un soleado loft rodeado por los tejados de Berlín.

…Mainnet.

En el transcurso de la semana, se completaron las siguientes tareas y se fusionaron en la rama principal:

  • Forcing Progress en cadena al cerrar un state channel. Para proporcionar esto, tuvimos que:

-> Implementar una prueba de inclusión que proporcione toda la información requerida para la ejecución del contrato, de modo que un contrato pueda forzarse en la cadena

-> Introducir un nuevo tipo de transacción, channel_force_progress como parte del protocolo

-> Desarrollar la exposición a la WebSocket API

-> Hacer consciente el progreso de la fuerza FSM

-> Incluir la cuenta del contrato en la prueba de inclusión del contrato

  • También simplificamos el progreso forzado de la transacción en cadena:

Inicialmente, el progreso de la fuerza requería una transacción completa y firmada fuera de la cadena para describir la actualización que se aplicará y el nuevo estado (tanto state_hash como una ronda). Vino con las siguientes condiciones:

-> Solo se aplica una actualización a la vez

-> Solo el From se permite ser el que llama

-> La ronda de solo_payload debe ser la siguiente ronda de la carga útil co-firmada

-> solo_payload está firmada por el from

Hicimos esto mucho más simple al reemplazar el solo_payload con los siguientes campos:

-> update — la actualización que se aplicará, la persona que llama debe seguir siendo la cuenta From

-> state_hash — el siguiente hash de estado del canal

-> Establecer el key block’s coinbase en el benefactor de Bitcoin-NG para recompensar la minería según el algoritmo de consenso Bitcoin-NG

Por último, también se realizó una serie de correcciones de errores y realizamos optimizaciones menores.

Miembros del equipo de marketing también estuvieron presentes durante el workshop y actualmente están trabajando en un resumen más profundo. Será publicado en el blog muy pronto, ¡así que estén atentos!


¿Interesado en æternity? Síguenos:

GitHub | Forum | Reddit | Telegram | Twitter | Facebook | Mail


Leave a Reply

Your email address will not be published. Required fields are marked *