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

gravatar
By admin
 · 
September 19, 2018
 · 
2 min read

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

Tagged: æternity · Blockchain · Español · Github · Spanish
Comments

No Comments.