![](https://cdn-images-1.medium.com/max/1200/1*TRKQZiun_k2yB9Y1do6FYA.png)
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.
![](https://cdn-images-1.medium.com/max/400/1*h9RotGUPQ5_bpU1-cIicQA.jpeg)
![](https://cdn-images-1.medium.com/max/400/1*Izn2gxaDWjxlwxOOqYeY8w.jpeg)
![](https://cdn-images-1.medium.com/max/400/1*MQ4zyc6N38rsuop2205G5w.jpeg)
![](https://cdn-images-1.medium.com/max/600/1*M0tJZHRQcVss0Tt2Opa90w.jpeg)
![](https://cdn-images-1.medium.com/max/400/1*1tJe2C5OEMR53BET2D-Rjg.jpeg)
![](https://cdn-images-1.medium.com/max/600/1*pKkrr7OPe1mu-xIqruoiwQ.jpeg)
![](https://cdn-images-1.medium.com/max/600/1*w8CXgEwBpWUy6bNefTTa3Q.jpeg)
![](https://cdn-images-1.medium.com/max/600/1*7_Sqsyyachi0jtiMR-mqAA.jpeg)
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.
![](https://cdn-images-1.medium.com/max/600/1*72cx3ps9M2_iVoVA94oJEQ.jpeg)
![](https://cdn-images-1.medium.com/max/600/1*CpK3C7ayZ-zKvkGnLNpIJA.jpeg)
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
![](https://cdn-images-1.medium.com/max/800/1*cZpm4_4kt1WA9t5WUbU7SA.png)
Leave a Reply