Equipos apoyados por EF: Informe de desarrollo

Amigos,

Durante el último año, los desarrolladores e investigadores apoyados por la Fundación Ethereum han mantenido la cabeza baja y han seguido produciendo a un ritmo asombroso.

Su enfoque se ha mantenido en su trabajo, y juntos estamos construyendo un Ethereum más completo. Hoy, nuestra serie regular de actualizaciones para todo el equipo se está reiniciando en un ecosistema cambiado y en constante crecimiento. Ethereum cuenta con dApp, desarrolladores y comunidades de usuarios más grandes que nunca, la red ha seguido mejorando y se han realizado progresos constantes en iniciativas grandes y pequeñas.

Si bien muchos equipos lanzan sus propias actualizaciones completas, pensamos que era apropiado traer a la comunidad lo último de muchos de los equipos (algunos de los cuales son más hablados) apoyados por la Fundación. ¡Disfrutar!

Aleth / C ++ Ethereum

En preparación para la actualización de Constantinopla / Petersburgo, Aleth tuvo varios lanzamientos: a partir de la serie 1.5.x y finalizando con la última 1.6.0. Aleth recibió muchas mejoras de nivel de red p2p, incluido un cliente de descubrimiento devp2p independiente llamado aleth-bootnode, y es compatible con la última revisión de Ethereum.

Registro de cambios: https://github.com/ethereum/aleth/blob/master/CHANGELOG.md

El proyecto EVMC continúa avanzando al recibir nuevos enlaces de idioma y otras mejoras, mientras que ABI sigue siendo compatible con la versión 6.

Registro de cambios: https://github.com/ethereum/evmc/blob/master/CHANGELOG.md

Por último, la biblioteca Ethash (https://github.com/chfast/ethash) ha recibido soporte para ProgPoW y algunas correcciones y mejoras de integración.

Registro de cambios: https://github.com/chfast/ethash/blob/master/CHANGELOG.md

DevOps

Hay cinco áreas principales en las que se utilizan los recursos de los devops: sitios web, Bootnodes, Geth, Swarm y Testing. Devops continúa mejorando nuestro proceso de implementación de infraestructura, principalmente con Ansible y Terraform, pero también con Kubernetes. También estamos haciendo un mejor trabajo documentando y rastreando la forma en que la infraestructura es utilizada por todos los equipos de desarrollo.

Un mini-proyecto que se completó recientemente es reunir las últimas referencias de código de EthStats y crear un lanzamiento y un nuevo repositorio que llamamos "EthStats Classic" (https://github.com/ethereum/eth-netstats). Alethio EthStats es el 2.0 y será mantenido por el equipo de Alethio (https://github.com/Alethio/ethstats-network-dashboard).

Desde el equipo de Swarm: estamos construyendo herramientas con Kubernetes que nos ayudan a aprovisionar rápidamente una variedad de implementaciones de Swarm con hasta 1000 nodos de Swarm, listos para usar con herramientas de rastreo, monitoreo y visualización de datos, que ayudan a nuestro desarrollo. y los esfuerzos de prueba. Estas herramientas nos permiten ejecutar una serie de pruebas de extremo a extremo, así como simular diferentes escenarios y simulaciones de red. También realizamos pruebas de integración periódicas en implementaciones más grandes además de nuestro conjunto de pruebas de prueba de prueba antes de cada lanzamiento, asegurándonos de no introducir regresiones ni degradación del rendimiento en Swarm.

DevP2P Design

A principios de 2019, DevP2P Design completó el trabajo en algunas tareas clave:

• EIP-778 (Ethereum Node Records) fue aprobado en la llamada a allcoredevs.

• Las especificaciones de protocolo de eth / 63 y les / 2 se han trasladado al repositorio https://github.com/ethereum/devp2p desde las páginas wiki de GitHub.

• Se han publicado los borradores iniciales de la especificación Node Discovery v5.

Mientras tanto, estamos trabajando arduamente para finalizar la especificación de Node Discovery v5. Las especificaciones de los protocolos "par", "pip" y "shh" se están adaptando para su publicación en el repositorio de devp2p y la implementación de EIP-868 y Node Discovery v5 en Geth . También estamos trabajando en un EIP para RLPx v6, que solucionará algunos problemas de cifrado y en la integración de los registros de nodo EIP-778 en el protocolo de enlace.

Las extensiones de ENR y las herramientas de desarrollo de soporte se han agregado a Geth, como una extensión de v4 y como parte de v5. El protocolo Discovery v5 y la implementación de Geth están a punto de completarse a medida que se realizan los refinamientos, y se están introduciendo auditores externos al protocolo para una auditoría de seguridad. Discovery v5 está recibiendo mucho interés por parte de la comunidad de implementadores de Eth 2.0, y Felix ha asistido a reuniones con ellos para ayudar a responder preguntas sobre dónde se complementan los protocolos entre sí.

El repositorio de devp2p continúa ganando terreno como el hogar de los protocolos de comunicación de Ethereum, con una serie de interesantes propuestas en revisión y documentación como LES y PIP completada. Se ha desarrollado mucho trabajo y discusión detrás de escena sobre LES y su dirección futura. Una serie de mejoras en la estructura y robustez del código LES se encuentran en la línea de solicitud de extracción de Geth (un gran saludo a Gary Rong) que aborda preocupaciones inmediatas, mientras que la dirección a largo plazo se está investigando y estableciendo. En las próximas semanas, el equipo de Geth se reunirá para consolidar las ideas y tomar una decisión sobre la dirección de LES y su implementación.

Becas EF

Durante el primer trimestre de 2019, anunciamos públicamente Wave 5 y lanzamos más destinatarios en el escenario en Ethereal. Ha sido un momento extremadamente emocionante para el programa, ya que hemos ampliado silenciosamente nuestro alcance para abarcar diferentes tipos de proyectos y explorado más formas en que podemos apoyar a la comunidad.

Mientras continuamos aceptando nuevas aplicaciones, también estamos obteniendo activamente aplicaciones de alta afinidad de desarrolladores e investigadores. Además, publicaremos (en los próximos meses) una retrospectiva del concesionario destacando el impacto de las subvenciones pasadas y los grandes equipos detrás de los proyectos.

El objetivo del programa es no solo brindar apoyo financiero, sino también brindar un apoyo personalizado para equipos de alto potencial, que incluyen apoyo de investigación, conexiones, comunicaciones y más. Al aumentar el sistema de apoyo e incorporar más voces, nos mantenemos fieles a la misión de descentralizar el proceso de toma de decisiones, así como a hacer todo lo posible para promover el ecosistema. ¡Mantente sintonizado para más!

EthereumJS

Nuestro enfoque dentro del equipo de EthereumJS es servir a la comunidad con implementaciones robustas y de alta calidad de JavaScript / TypeScript de Eth 1.0 de capa base y cada vez más tecnologías y protocolos de Eth 1.x. Consulte nuestra documentación organizativa en ethereumjs.readthedocs.io para obtener una introducción sobre lo que estamos haciendo y algunos puntos de entrada clave para nuestro trabajo.

Mecanografiado

El centro de atención en la primera parte del año fue la transición de nuestra base de código a TypeScript y estamos casi terminando en nuestras bibliotecas más utilizadas. Hemos lanzado las versiones TypeScript de los bloques de construcción principales como nuestra blockchain y las bibliotecas de transacciones (esta última también ahora con soporte completo de hardfork y protección de reproducción EIP-155); aquí hay una PR abierta con una reescritura completa de la biblioteca devp2p en TypeScript que espera ser fusionado (felicitaciones a Dmitriy Ryajov de MetaMask / Mustekala); y, probablemente la pieza más emocionante, la transición de nuestra implementación de VM a TypeScript se ha completado y ya se ha fusionado en la rama maestra. ¡Esté atento a una versión beta a seguir en los próximos días!

VM

Sabemos la importancia de una máquina virtual de JavaScript bien estructurada, modular y expandible para la realización de una potente funcionalidad de análisis y depuración dentro de las herramientas de desarrollo como Remix, Truffle y otras. Con este fin, otro enfoque actual de los últimos meses fue hacer fuertes movimientos hacia estos objetivos y realizar un importante trabajo de refactorización en la máquina virtual. Realizada principalmente por nuestra nueva empleada Sina Mahmoodi, la próxima versión de VM v4 se enviará con un manejo de memoria y pila mucho más explícito y legible, modernización de código con la introducción de clases ES6 y uso asíncrono / espera así como una refactorización general y modularización del Estructura del código específico de EVM. Este último, junto con una interfaz de entorno similar a la EEI recientemente introducida para acceder a los datos de la cadena de bloques, se encuentra en preparación para una integración de eWASM ya en el trabajo dentro de la VM.

Otras investigaciones

También estamos dedicados a continuar brindando soporte y manteniendo nuestra base de código existente para mantener nuestras bibliotecas seguras, sólidas y de alto rendimiento. La última experimentación que sigue estos objetivos se relaciona con el uso de módulos WASM para primitivas criptográficas, el uso de BigInt en JavaScript / TypeScript junto con el manejo de números de ancho fijo, así como un manejo y conversión de valores hexadecimales y de búfer más propensos a errores. Le haremos saber una vez que tengamos resultados concretos para compartir en estos diversos frentes.

Ewasm

Los últimos meses han sido muy ocupados y fructíferos. Para garantizar que Ewasm esté bien diseñado como capa de ejecución, el proceso de diseño se basa en prototipos, análisis y evaluaciones comparativas. En el primer trimestre comenzamos estudios extensivos de evaluación comparativa de los motores de ensamblaje web y los motores EVM. En el segundo trimestre lanzamos Scout, un motor de ejecución prototipo para Ethereum 2.0. Nuestro enfoque en el tercer trimestre será la iteración continua en los prototipos, informados mediante análisis y puntos de referencia.

Ewasm durante Q1 2019

Benchmarking

A medida que avanzaba la evaluación comparativa, surgieron nuevas preguntas que requerían evaluaciones comparativas más detalladas y, en ocasiones, nuevas infraestructuras. La evaluación comparativa tiene como objetivo responder preguntas abiertas, incluidas las relacionadas con:

* diferentes motores de ensamblaje web (incluidos intérpretes y varios tipos de compiladores)

* Varias implementaciones de Ethereum precompila.

* Implementación de los mismos contratos en WebAssembly y EVM.

* Diferentes estrategias de medición.

Los motores de ensamblaje web (Wasm) comparados incluyen un número significativo de motores independientes, así como los motores Wasm que hemos integrado en los clientes de Ewasm (a través de Hera).

Para la comparación de precompilaciones, hemos utilizado go-ethereum, implementaciones de Rust compiladas de forma nativa e implementaciones de Rust compiladas con Wasm. La implementación de Rust de cada precompilación de Constantinopla se puede encontrar en ewasm-precompiles. También hemos utilizado varias versiones C optimizadas manualmente.

Para la comparación de EVM, hemos seleccionado implementaciones de contratos de EVM optimizadas e implementamos contrapartes en WebAssembly. Los bytecodes de EVM se compararon utilizando go-ethereum, parity-ethereum y evmone. Estas comparaciones han sido especialmente fructíferas, revelando nuevos objetivos y requisitos para nuestro diseño.

La estructura de WebAssembly es muy adecuada para las optimizaciones de medición. Se desarrollaron y evaluaron varios prototipos de medición, con atención a las clases comunes de contratos y tipos de motores de ensamblaje web.

Los resultados sobre EVM se publicaron en el segundo trimestre (ver más abajo). Informar sobre resultados adicionales, incluido un análisis en profundidad de los motores de ensamblaje web, es un trabajo en progreso y se publicará en futuras publicaciones.

Precompilaciones

La implementación de todos los de Constantinopla, así como cuatro precompilaciones recientemente propuestas (blake2, ed25519, bls12-381, sha1) se completaron y están disponibles en el repositorio de precompilaciones de ewasm.

Tuvimos éxito en la sincronización de toda la cadena Rinkeby utilizando estas implementaciones en go-ethereum.

Et 1.x

Algunos miembros del equipo participaron en las reuniones Eth1.x / Istanbul en San Francisco y Berlín. Dimos actualizaciones sobre nuestro progreso y presentamos algunas de las propuestas de EIP para Estambul, que tienen un significado para Ewasm. Tres áreas notables de cambio son los mejores límites de protocolo, la separación de init y el código de tiempo de ejecución y las versiones de la cuenta.

Et 2.0

El equipo de Ewasm ha mantenido discusiones con el equipo de investigación Eth 2.0 sobre la Fase 2. Compartimos preguntas abiertas, consideraciones de diseño e ideas. El equipo de Ewasm participó, en su mayoría de forma remota, en la reunión de investigación Eth 2.0 antes de EDCON en abril. El objetivo era discutir los requisitos del motor de ejecución para Eth 2.0.

Nuestras propuestas se rastrean en nuestro repositorio de diseño (https://github.com/ewasm/design/issues).

Testnet

El testnet se mantiene activamente en ewasm.ethereum.org. Los contratos se pueden redactar en Rust usando herramientas de Rust (ewasm-rust-api y cincel), que se han mejorado. Los contratos también se pueden escribir en C, que tiene una cadena de herramientas menos desarrollada.

Ewasm durante Q2 2019

Et 1.x

Hemos publicado una subsección del informe de benchmarking: EVM benchmarks. Los resultados demuestran el potencial para reducir significativamente el costo de gas de los códigos de operación en EVM, lo que nos motiva a proponer EIP-2045: costos de gas de partículas para los códigos de operación de EVM.

Los puntos de referencia EVM resaltan los nuevos récords de velocidad establecidos por la implementación optimizada de EVM: evmone. Creado en un esfuerzo conjunto de los equipos Ewasm y Aleth / C ++, evmone está diseñado para ser importado como un módulo de ejecución por cualquier cliente de Ethereum. Se está realizando un análisis adicional de la aceleración alcanzada por evmone y las posibles reducciones de los costos de gas en EVM.

Et 2.0

Lanzamos Scout, una herramienta de creación de prototipos para los scripts de ejecución de Wasm en Ethereum 2.0. El lanzamiento de Scout se anunció en ethresearch aquí y se presentó en la conferencia Scaling Ethereum en Toronto (video aquí).

Scout es un prototipo de un nuevo enfoque para la ejecución en Ethereum 2.0 basado en "entornos de ejecución". Se necesita más experimentación y análisis para determinar si los entornos de ejecución pueden cumplir con los requisitos de Ethereum 2.0, y Scout está diseñado para ejecutar tales experimentos. Varios investigadores y desarrolladores están entusiasmados con este nuevo enfoque (consulte la actualización sobre Serenidad del equipo de Investigación, a continuación).

Wasm en el Blockchain

El equipo de Ewasm realizó cuatro presentaciones en Berlín en el taller inaugural de Wasm on the Blockchain. Los videos del evento aún no se han subido, pero las diapositivas están disponibles:

Algunos miembros del equipo de Ewasm también participaron en la reunión de junio del Grupo de la Comunidad de WebAssembly. Esto nos ha permitido comprender y discutir las próximas propuestas para el montaje web, muchas de las cuales son relevantes para Ewasm. Las notas de la reunión del grupo de la comunidad están disponibles en el repositorio de reuniones / reuniones web.

Geth

El equipo de Geth ha estado trabajando en la próxima versión principal, v1.9.0, que ha estado en los trabajos durante la mayor parte de 4 meses. Algunos enigmas que hemos caído en el camino giran en torno a importantes mejoras de rendimiento Para nodos de archivo y significativos. reducciones de almacenamiento para nodos completos. Estos parecen ser confirmados por externo entidades también, así que estamos muy contentos con ellos. También hemos estado trabajando en un nuevo formato de base de datos que permite mover una gran parte (estimada en, según un punto de referencia reciente) de los datos de un nodo completo (no archivado) a un disco duro, lo que hace que sea más fácil y más económico ejecutar los nodos de Ethereum.

Red de nivel inferior: el equipo se ha centrado en las nuevas especificaciones de descubrimiento (ENR y compañía), con el objetivo de reemplazar tanto la v4 antigua (utilizada por el nodo completo) como la v5 hacky (utilizada por los clientes livianos de Geth). Esta será la primera actualización real de esta infraestructura en los últimos 4 años, por lo que tenemos muchas lecciones que incorporar. El objetivo es construir un sistema mucho más robusto que pueda soportar la coexistencia de protocolos (archivos) de nivel superior y redes múltiples de Ethereum (red principal, redes de prueba, etc.).

Redes de nivel superior: el protocolo de cliente ligero incluye búsquedas de transacciones por hash y nuevas API de RPC para dar soporte al servicio prioritario para los clientes que pagan. El equipo revisó las instrucciones para los protocolos LES y PIP, y acordaron comenzar a establecer direcciones comunes entre Geth y Parity. La primera reunión entre equipos se acerca en mayo.

También nos hemos centrado en separar la gestión de cuentas de Geth en su propia aplicación de firma llamada Clef. La primera versión será solo para CLI, pero hemos estado trabajando en múltiples IU de prueba de concepto para asegurarnos de que nosotros y otros podamos construir sobre los bloques de construcción que Clef proporciona. El objetivo de Clef es proporcionar una manera segura de administrar sus cuentas de Ethereum que puedan manejar tanto las llaves como las carteras de hardware; ¡pero lo más importante, uno que pueden usar todas las aplicaciones DApp en su sistema sin tener que enrollar sus propias cuentas!

Otras características más pequeñas en las que hemos estado trabajando incluyen una API basada en GraphQL para consultar datos de la cadena, soporte integrado para carteras de tarjetas inteligentes, soporte actualizado para el libro mayor, soporte para monitoreo de Prometheus (además de InfluxDB que ya hemos implementado), BlockScout integración en Puppeth, y más.

A medida que nos acercamos de forma extraña a la versión 1.9.0, hemos reducido esta sección y haremos una publicación de blog ampliada en las próximas semanas.

Cuadrícula

El Mist Browser estaba al atardecer, pero nació Ethereum Grid. Grid es una aplicación de escritorio que permite a los usuarios descargar, configurar y usar de forma segura varios clientes y herramientas en el ecosistema Ethereum. Entre sus beneficios potenciales, Grid puede:

1) permitir que una audiencia menos técnica interactúe de forma segura con herramientas técnicas

2) Ayudar a que los proyectos en el ecosistema alcancen audiencias más amplias.

3) proporcionar una plataforma para acelerar la piratería en Ethereum.

¡Al equipo de Grid le encantaría su opinión sobre el software alfa y recibir noticias de proyectos interesados ​​en crear un complemento en la plataforma!

Luna

¡Nuestros logros recientes están disponibles en nuestra hoja de ruta como publicación escrita de principios de año! Compruébelo en github: https://github.com/moonad/roadmap.

Jugar

Meet Play: Herramientas para la educación descentralizada

Play lanzó nuestra primera herramienta hace un mes: un editor de Solidity que se puede insertar. Puede pegar el código de solidez y obtener una vista previa en vivo que le permite publicar el contrato e interactuar con él en cadena. El juego se puede incrustar en cualquier sitio o aplicación, para demostrar su contrato inteligente, enseñar, lo que sea. Pruébelo en https://play.ethereum.org/editor-solidity/

También acabamos de lanzar nuestra segunda herramienta, un taller estático / generador de tutoriales.

Mantente sintonizado y conéctate con el equipo de Play https://twitter.com/play_ethereum

Ecosistema Python (PyEVM / Trinity / Web3.py / Vyper)

Web3.py

Web3.py ha estado trabajando hacia una versión beta de v5. La versión 5 incluye trabajo para estandarizar las API RPC compatibles basadas en EIP-1474, una nueva API para leer de los contratos implementados, implementando estándares de firma como EIP-712 y EIP-191, así como muchas correcciones de errores. Web3.py v5 también incluye una nueva API de administrador de paquetes experimental. Ver las notas de la versión para más información.

Vyper

Vyper se ha beneficiado de una serie de tareas de limpieza interna. Los ejemplos de esto incluyen cosas como una revisión exhaustiva de la pelusa, la adición de anotaciones de tipo a ciertos módulos de código y la verificación automatizada de esas anotaciones, las mejoras generales al equipo de prueba de Vyper y la tubería de integración continua, y varios refactores de código. Todo esto fue parte de un impulso continuo en todo el proyecto para mejorar la mantenibilidad y la legibilidad. El objetivo a largo plazo de este impulso es facilitar que los nuevos contribuyentes se unan al proyecto.

Vyper también continúa agregando características planeadas. Para obtener más información, visite los temas de github de Vyper y las páginas de solicitudes de extracción

Trinidad

Trinity ha seguido mejorando con muchas correcciones de errores, mejoras de rendimiento y soporte de Constantinopla. También hemos estado trabajando para hacer que la base del código sea más modular para aumentar la capacidad de mantenimiento y la reutilización del código entre las partes de Ethereum 1.0 y 2.0 de la base del código. Trinity continúa mejorando su arquitectura basada en eventos y soporte de extensibilidad.

Además, Trinity ha recibido muchas actualizaciones trabajando para una primera red de prueba Ethereum 2.0. Continuamos colaborando con el equipo de investigación para integrar Eth2 en Trinity.

En las noticias de Eth1.0: actualmente estamos experimentando con una nueva función que llamamos Beam Sync. Imagine iniciar un nodo Trinity y comenzar a procesar los últimos bloques y atender las solicitudes de RPC en minutos. Beam Sync verificará los bloques a medida que se extraigan al dar prioridad a la sincronización del estado utilizado en los últimos bloques.

Y finalmente, en el frente de Eth1.x, hemos estado trabajando en el protocolo de sincronización de Firehose, un nuevo protocolo de sincronización de estado que reducirá radicalmente la cantidad de tiempo necesario para iniciar un nodo y descargar todos los datos necesarios para ser el primero. nodo de clase en la red Ethereum. Firehose y Beam Sync se potencian mutuamente. Beam Sync es posible con la red actual, pero se mejorará drásticamente con el protocolo Firehose Sync.

eWASM

También hemos estado preparando algunas bases para eWASM en los últimos meses. La biblioteca py-wasm ahora tiene una implementación completamente funcional del intérprete de ensamblaje web y hemos comenzado el trabajo preliminar para integrarlo en Py-EVM para implementar un entorno de ejecución basado en EWASM para contratos inteligentes.

Etpm

EthPM ahora está completamente integrado en Web3.py v5. ERC 1319 se ha actualizado para incluir algunos eventos y funciones útiles. Se construyó un explorador de registro para proporcionar una interfaz para interactuar con varios registros de EthPM. Se está trabajando en una utilidad de CLI para descargar paquetes de EthPM en el disco.

Remezclar

Finalmente lanzamos Remix 0.8, que viene con un rediseño masivo de UX y la integración de una versión más estable de la API del complemento de remix. La documentación se ha mejorado y se seguirá mejorando con futuras actualizaciones. Echa un vistazo a la versión 0.8.0 en Github, la aplicación actualizada y nuestra publicación Medium.

¡Estamos actualizando regularmente https://remix-alpha.ethereum.org con el último progreso!

También hemos visto la integración de remix-tests y remix-debug en Embark y EtherAtom, comenzamos a migrar la base de código de remix a TypeScript y el esperado soporte del nuevo AST;).

A partir de la versión 0.8, nos esforzaremos más en escribir y promocionar contenido educativo, primero para la pila Remix y luego más ampliamente para el ecosistema Ethereum.

Tenemos la intención de lanzar versiones de Remix de parches más regularmente ahora, y poner en marcha un sitio web de Remix pronto.

Es de esperar que la versión de escritorio (que se puede usar fuera de línea) aterrice pronto (parte del trabajo ya se ha realizado con la integración de Grid y necesitamos verificar cómo podemos fusionar esfuerzos aquí).

Continuaremos perfeccionando la API de remix-plugin y mejorando el dev de UX durante las próximas semanas. Ahora que la capa base está lista, debemos aprovechar el almacenamiento descentralizado para alojar complementos. Esto probablemente llevará unos pocos meses.

Además, queremos continuar escribiendo tutoriales, talleres y hacer lo necesario para la incorporación de principiantes.

Investigación (CBC)

Objetivos para el 2019:

1. Producir pruebas de vida para una variedad de suposiciones de sincronía, y para requisitos de vida probabilísticos y deterministas.

2. Produzca una especificación de fragmentación de Devcon 5, completa con la regla de elección de la horquilla de mensajería de fragmentos cruzados y (posiblemente) un equilibrador de carga.

Trabajo completado en enero-junio de 2019:

1. Inspector de finalidades – Taller de investigación de Stanford, febrero de 2019

• El Inspector de finalidades es un algoritmo que encuentra la puntuación de finalidad de un bloque determinado (el peso de los validadores que deben equivocarse para que se pueda revertir el bloque determinado) buscando un criterio de finalidad en el mensaje DAG. El algoritmo es bastante eficiente: se ejecuta en tiempo polinomial en el número de validadores totales.

2. Documentación para el inspector de finalidades – ETHParis, marzo de 2019

• Hicimos una publicación de blog informativa que describe al inspector de finalidades y muestra una ejecución del protocolo (para consenso binario) y el nivel de finalidad sobre los valores propuestos.

3. Estrategias de vitalidad – Mayo de 2019

• Hasta ahora hemos creado 3 estrategias de vida para la familia de protocolos CBC Casper.

4. Algoritmos de elección de horquilla LMD GHOST – IC3 Boot Camp, junio de 2019

• Describimos un algoritmo eficiente para mantener la punta LMD GHOST ganadora de la cadena de bloques. Al ver un nuevo bloque, actualiza la punta LMD GHOST en tiempo O (V ^ 2) (sin datos adicionales almacenados en bloques), o tiempo O (V * log (V)) (si los bloques almacenan una lista de omisión de sus bloques de antepasados). Este algoritmo también se puede utilizar para ejecutar la sección LMD GHOST de la opción de horquilla Eth 2.0.

Alcance comunitario en enero-junio de 2019:

1. Vlad @ Stanford Blockchain Conference, febrero de 2019

2. Vlad, Aditya @ ETHCC, marzo de 2019

3. Vitalik, Aditya @ EDCON, abril de 2019

4. Vlad @ CryptoChicks, junio de 2019

Investigación (Plasma)

El envío de una implementación de Plasma de extremo a extremo proporcionó una perspectiva que fue fundamental para obtener un plasma generalizado. Esta idea surgió del hecho de que nuestra red de pruebas tenía un propósito demasiado especial y nos dimos cuenta de que necesitábamos la capacidad de actualización. No habríamos llegado a esto si no nos hubiéramos enfrentado a la dura verdad de que llevar nuestra implementación actual a producción sería muy limitado. En cambio, una inversión de tiempo relativamente pequeña en un rediseño ayudó a nuestro diseño a prueba de futuro.

Los anuncios de la primera parte del año incluyen:

El trabajo en curso se centra en la producción de pagos de plasma. En los próximos meses, llevaremos el plasma generalizado a producción con una red de pagos escalable y completamente auditada. Los próximos pasos serán abordar:

Plapp Plapp.

Investigación (Serenidad)

tldr; está sucediendo

Fase 0

La cadena de balizas ha pasado por una serie de lanzamientos iterativos, y es en gran medida estable a medida que los equipos de clientes implementan. Se está trabajando mucho en las pruebas y auditorías a medida que nos acercamos al final de la Fase 0 de junio, congelación de especificaciones. Ahora existe una amplia gama de vectores de prueba de consenso que están siendo aprobados por los equipos de clientes, y ahora hay un esfuerzo de fuzzing en curso, fuzzing la especificación de python y go spec con la intención de fuzzing clientes pronto. La verificación de tiempo de ejecución también ha comenzado formalmente especificando la cadena de balizas en K y verificando formalmente el contrato de depósito de Vyper.

Hay algunas redes de prueba de un solo cliente con participación pública. En los próximos meses, esperamos ver redes de prueba públicas de clientes múltiples de corta duración y de larga duración.

Gran parte del trabajo de la Fase 0 está ahora en manos de los equipos de los clientes para llevar la cadena de balizas a la producción. La lista de tareas del cliente incluye: pruebas de consenso, optimizaciones, agregación eficiente, redes p2p estables, sincronización de estado, UI / UX del validador, revisiones de seguridad, herramientas de visualización … Gracias (o fondo) a su equipo local de clientes la próxima vez que tenga una oportunidad. Son los héroes olvidados en este proceso y merecen mucho más apoyo y elogios.

Fase 1

La especificación de la Fase 1 en las cadenas de datos de fragmentos está principalmente implementada y ha pasado por muchas simplificaciones en los últimos meses. La mayoría de estas simplificaciones se manifiestan en el "juego de custodia", reduciendo la complejidad de la computación y la complejidad de los juegos de desafío cuando los datos no están disponibles. El juego de custodia ahora es más compatible con la computación multipartita para ayudar a fomentar grupos de apuestas descentralizadas.

Recientemente, la Fase 1 se convirtió en ejecutable y se ha integrado en el conjunto de pruebas de especificaciones. Esta especificación debe ser iterada, simplificada y prototipada en los próximos meses.

Fase 2

La fase 2 tiene algunas investigaciones interesantes en curso. Se ha realizado un gran esfuerzo para simplificar y abstraer la capa de consenso de ejecución a través de una nueva ruta denominada "entornos de ejecución". Los entornos de ejecución abren un mundo de posibilidades en la forma en que se puede usar la capa de datos altamente escalable de Eth 2.0. En particular, podría permitirnos ubicar Eth1 en Eth2 para permitir una transición más fluida para la comunidad. Gran parte de la investigación y el debate sobre la Fase 2 se están realizando en http://ethresear.ch/, ¡así que échale un vistazo!

Clientes ligeros

Existe una especificación de cliente ligero que se basa en la Fase 1 y se trabajará de manera iterativa en el próximo trimestre. Esperamos ver un par de implementaciones de clientes ligeros en las que se trabaja en Q3 o Q4 después de que las implementaciones de la cadena de balizas centrales se estabilicen.

Seguridad (Seguridad / Pruebas de consenso)

Hemos realizado una medición bastante extensa de la ejecución de los códigos de operación dentro de Geth, para proporcionar antecedentes y análisis para https://eips.ethereum.org/EIPS/eip-1884, cuyo objetivo es reequilibrar los códigos de operación que de otra manera conducirán a una degradación severa del Red Ethereum.

El marco de trabajo de Hive se ha actualizado, y nuevamente se está ejecutando en https://hivetests.ethstats.net/, y también hemos vuelto a lanzar un difusor diferencial de paridad geth / parity basado en libfuzzer en un entorno de producción. Planeamos lanzar públicamente este fuzzer en el futuro a medio plazo.

Retesteth estabilidad se ha restaurado. También hemos corregido errores al ejecutar StateTests y BlockchainTests a través de la interfaz test_ RPC en aleth. Retesteth ahora se puede construir en la ventana acoplable y ejecutarse contra cualquier cliente que admita la interfaz test_ RPC. Geth + retesteth soporte ahora ha sido habilitado.

Proyectos especiales

• Colaboraciones con Microsoft para crearnos un entorno de desarrollo integrado superior, como el banco de trabajo de cadenas de bloques de Azure.

• Se ha completado el cumplimiento de la Shariah de Ether. Los detalles de la fatwa de Amanie Advisors serán anunciados. Con suerte, esto traerá más usuarios y aplicaciones del mundo islámico. Inclusión financiera y nuevos mercados.

• Lanzamiento del proyecto abierto Ethereum OASIS para intentar endurecer la batalla y traer un poco más de estructura a nuestro proceso de estándares.

• Se lanzó una nueva wiki: eth.wiki (todavía un trabajo en progreso).

• Trabajar con el Instituto Santa Fe para desarrollar un programa de investigación criptoeconómica. Recientemente, enviamos Shruti Appiah de Consensys a Santa Fe para hablar sobre economía de fichas.

• EF desea mejorar el juego de Ethereum en el espacio empresarial. Ergo, hemos estado chateando más con Ethereum Enterprise Alliance y Hyperledger. Hasta ahora, la Fundación Ethereum se ha unido a ambas organizaciones y estamos descubriendo próximos pasos plausibles.

• Exploraciones de colaboración en curso con:
• ¡Un montón de botín nuevo en la tienda de botes Ethereum!

Solidez

Los puntos de enfoque actuales para el desarrollo de Solidity son los siguientes:

• puliendo el ABIEncoderV2 para una versión no experimental,

• Incrementando la cobertura del módulo de verificación SMT,

• trabaje en el Optimizador de Yul y el generador de código de Solidity a Yul (los contratos simples como un token ERC20 ya funcionan)

• generación de código de Yul a eWASM asumiendo todos los tipos o 64 bits de ancho

• Fuzz sintáctico y semántico de varios componentes.

• Cambios de planificación para la próxima versión de lanzamiento 0.6.0

Durante las semanas anteriores, permitimos el acceso al compilador y optimizador de Yul mediante standard-json. También es posible acceder al generador de código de Solidity to Yul usando el --se cambiar. Por razones de seguridad, debe compilar este código yul nuevamente para codificarlos manualmente. Por favor, intente esto, pero tenga en cuenta que ambas partes aún son experimentales. Además, estamos agregando más controles a la parte del decodificador del componente ABIEncoderV2 que evita que los datos no válidos pasen por el proceso de decodificación.

Enjambre

Swarm vio mejoras significativas en la estabilidad, especialmente en el fortalecimiento del código de conectividad de la red, así como en la integración del nuevo LocalStore con una recolección de basura confiable. Nuestra infraestructura de desarrollo y aprovisionamiento de clústeres se graduó y permite probar el comportamiento complejo de la red en un clúster de hasta 1000 nodos.

Las mejoras en las pruebas de depuración, rastreo, métricas y simulación de red ahora se complementan con pruebas de humo de extremo a extremo. Dichas pruebas se ejecutan regularmente en implementaciones y permiten un monitoreo continuo del rendimiento. Dado que coinciden estrechamente con el uso real, modelan la percepción del usuario y se utilizarán para justificar los cambios de implementación o las regresiones de captura.

El lanzamiento v0.4 recientemente trajo un testnet mucho más confiable. La versión 0.4 ahora presenta oficialmente ACT (módulo de control de acceso de Swarm) que permite a los usuarios controlar el acceso a contenido compartido o a los desarrolladores para ofrecer áreas / funciones protegidas autenticadas de dapps. También incluirá alimentaciones de enjambre mejoradas.

Continuamos con la reestructuración de los métodos de trabajo, más trabajos de ingeniería de principios, principios de código limpio.

Swarm ahora lanzó un subequipo de productos y consolidó nuestra hoja de ruta adoptando un enfoque de MVP más centrado en el usuario para los hitos.

Otras actualizaciones recientes se capturan aquí: https: //github.com/ethersphere/swarm/blob/master/CHANGELOG.md
Finally, we had the Swarm Orange Summit in Madrid and that was very successful and well received!

Web3.JS

The newly introduced architecture (1.0.0-beta.38) of Web3.js is under active development and is improving day by day. We have implemented the possibility to pass a custom transaction signer, to configure the transaction confirmation workflow, new modules (Admin, TxPool, Miner, Debug), and some new methods for the Eth module (getChainId, requestAccounts, getPendingTransactions). To allow the new architecture to succeed, we’re allowing breaking changes by moving this work to a 2.0-alpha version of Web3.js. Because version 1.0.0-beta.37 is widely used and to allow bug fixes for them, we’ve decided to define beta.37 as 1.0 stable. This gives us the possibility to enable bug fixes for the old architecture of Web3.js while coexisting peacefully with the new and exciting 2.0-alpha architecture.

In Numbers:

📝 1486 commits

🔧 244 fixed issues

🏆 ~135000 lines of code added and ~165000 removed

🏆 17 Releases

The next steps of the Web3.js project will be explained in the coming announcement.

Whisper

We are improving compatibility with Parity’s version of Whisper. Our goal is to have a fully compatible WASM version of this, to simplify the usage of Whisper in Dapps.

Some discrepancy between the implementation and the spec has been found by status and has been fixed.

The documentation effort is well underway, and is available in the geth pages repository. The protocol details are to be moved to the Devp2p spec repo.

ZKSnarks Research

We are moving forward with zkrollup implementations, and we’re becoming more confident in using zkp (zero knowledge proofs) to scale arbitrary dapps to millions of users. Our goal is to provide zkrollup as a proof of concept and then start to explore scaling other kinds of dapps in this way.

High level languages are starting to mature which allow developers to build scalable dapps using snarks with less ramp up time. We are excited by these developments and excited to see developer adoption.

On the privacy front, we have built a generic zcash style circuit which can be used for coin mixing, voting, anonymous DAOs, anonymous social media, and in other cool privacy focused areas. Our next deliverable in this direction will be a mixer for erc20 tokens. From there comes the potential for more cool privacy projects like, anonymous journalism and voting.

ZoKrates

Over the last months, we’ve worked to achieve three main goals: to make ZoKrates more efficient, more powerful, and even easier to use.

We introduced support for Elliptic Curve Cryptography in ZoKrates programs and provided primitives leveraging EC cryptography, for example EdDSA verification, to developers. Together with other useful building blocks, these are now available as part of the ZoKrates standard library. This is accompanied by a new Python library called pycrypto which contains application code that makes it easy to interact with provable ZoKrates programs.

To make the most of these building blocks, we’ve improved optimizations for the ZoKrates compiler and started refactoring the module system to better support composition.

We have also specified the ZoKrates DSL grammar formally and are currently working on a more efficient parser implementation based on that specification.

As a step towards our goal of a Rust-only codebase, we added support for Bellman which enabled Mac OS X native builds as well as efficiency gains.

Finally, we extended our documentation (e.g., tutorial on how to proof pre-images of hashes) and released a blogpost which discusses the challenges of using zkSNARKs in dApps. For developer education, we conducted a workshop at the 2nd ZKProof Workshop, Berkeley. Further workshops are taking place in London and Split in June.