Saltar al contenido

Equipos apoyados por EF: actualización de investigación y desarrollo

Amigos,

Desde el último informe de Equipos con Apoyo de EF, se han realizado progresos en todos los ámbitos. Desde las condiciones mejoradas de la red hasta el próximo lanzamiento de Estambul y el desarrollo de Eth1.xy Eth2, todas las áreas centrales para la funcionalidad y sostenibilidad de Ethereum están avanzando.

Esta serie se enfoca en equipos y esfuerzos de la Fundación y un ecosistema Ethereum más grande que están trabajando para crecer y mejorar Ethereum en su conjunto. En esta edición, cubrimos actualizaciones de muchos equipos destacados en el informe anterior, proyectos totalmente respaldados que son elementos centrales del ecosistema Ethereum como Eth2.0 Research, Geth and Solidity, y otros esfuerzos del ecosistema.

¡Disfrutar!

Aleth / C ++ Ethereum

Escrito por Andrei Maiboroda

El equipo de Aleth fue uno de los equipos de clientes que trabajaban en la actualización de Estambul a la cadena Eth1.x, y Aleth 1.7.2 fue lanzado con pleno soporte para Estambul.

EVM y otro consenso

Hitos importantes para el proyecto evmone:

Después del lanzamiento inicial de esta implementación experimental rápida de EVM, nos enfocamos en exprimir aún más el rendimiento. los 0.2.0 el lanzamiento es ~ 66% más rápido que el anterior. Después de esto, el 0.3.0 El lanzamiento llevó a Evmone a la compatibilidad con las especificaciones de Estambul. Para aquellos más interesados ​​en los conceptos que evmone intenta explorar y para obtener más información sobre cómo optimizar EVM, consulte las diapositivas de Técnicas de optimización para implementaciones de EVM Presentación de Devcon5 y el Algoritmo de cálculo de gas eficiente para EVM artículo.

El proyecto EVMC (la API en varios idiomas para implementaciones de EVM) recibió las actualizaciones requeridas con soporte para Estambul. Todo esto está empaquetado como el EVMC 7.0.0 lanzamiento.

Hubo una serie de optimizaciones en el intérprete aleth para eliminar el acceso innecesario al estado en la implementación de algunos códigos de operación. Estas ineficiencias se hacen evidentes gracias al gran conjunto de pruebas EVM proporcionado por proyecto evmone.

El intérprete aleth también cambió de usar boost :: multiprecision a biblioteca intx. Este es un paso hacia el envío de un intérprete aleth sin dependencia de impulso, pero también permitió hacer algunos puntos de referencia interesantes para ver cuán ineficiente era la implementación de impulso de entero de 256 bits para nuestras necesidades.

Después de Estambul, optamos por implementar un par de EIP propuestos para el futuro hard fork (Berlín): EIP-1380 Costo de gas reducido para llamar a uno mismo y EIP-2046 Costo de gas reducido para llamadas estáticas hechas a precompilaciones. Estas implementaciones ahora se pueden activar en la herramienta de prueba, ver más abajo

Redes

Hemos implementado una optimización que ha sido adoptada por un tiempo por otros clientes de mainnet: propagar nuevos bloques a los pares inmediatamente después de la verificación de PoW en lugar de esperar una validación y ejecución completas. También hemos establecido un límite en la cantidad de transacciones previamente descartadas que el grupo de transacciones recuerda (ahora son 1024 de esas transacciones).

La versión del cliente informada durante el protocolo de enlace devp2p fue corregida y permitió que la versión de Aleth se mostrara correctamente en éternodes.

RPC

Hemos realizado una serie de correcciones para adaptarnos mejor a los formatos de entrada / salida utilizados en las interfaces RPC de otros clientes. Muchos métodos obtuvieron un aumento significativo del rendimiento gracias a una solución que eliminó las repeticiones innecesarias de transacciones en bloque. Esto puede notarse en casos de uso con muchas solicitudes RPC frecuentes, por ejemplo, cuando se usa vuelve a probar con aleth

Base de datos

La reconstrucción de los índices a partir de la base de datos de bloques existente se corrigió y optimizó, esto nos permitirá optimizar y modificar el diseño de la base de datos de índice en el futuro.

Herramienta de prueba

La estructura de la carpeta de pruebas de consenso fue reorganizada por el equipo de prueba, y ahora testeth lo admite: todas las pruebas que cubren las reglas de la bifurcación antes de Estambul están en la suite LegacyTests.

Las pruebas de estado ahora se pueden generar y ejecutar con una cadena como "ForkName + EIP_number" en lugar de un nombre de fork normal en la sección de espera. Esto permite que cualquiera que planee crear prototipos de EIP nuevos en aleth para generar pruebas para ellos antes de que EIP sea aceptado para la bifurcación: esta es la idea básica de Proceso de bifurcación centrado en EIP, siendo adoptado actualmente por la comunidad All Core Devs. Como ejemplo del mecanismo, dos nuevos EIPS mencionados anteriormente (EIP-2046 y EIP-1380) se pueden activar en las pruebas, y hemos creado un par de estado pruebas para ilustrar esta característica.

También hemos arreglado y simplificado la función de testeth para ejecutar cualquier archivo de prueba personalizado (fuera de la estructura de prueba de consenso predefinida) e hicimos que el resultado sea más conforme con la herramienta evm de go-ethereum. Esto nos permitió integrar las pruebas en goevmlab proyecto, y ahora la implementación de EVM de aleth está participando en un esfuerzo cruzado junto con otros 3 EVM de los principales clientes.

Entre otras mejoras:

Programa de apoyo al ecosistema

Escrito por el equipo ESP

Subvenciones específicas de Taiwán

Nosotros recientemente galardonado una ronda de cinco subvenciones de $ 2,000- $ 5,000 en Crosslink Taipei. Este es el más reciente de una serie de olas locales específicas destinadas a reconocer las contribuciones de las comunidades de todo el mundo.

Creciente apoyo no financiero

Continuamos ampliando nuestra definición de "apoyo" para proyectos donde una subvención regular no es la adecuada. Parte del apoyo no financiero que hemos brindado son rondas de comentarios con asesores expertos, conectando equipos que trabajan en cosas similares, crédito de AWS, invitaciones para participar en eventos y más.

Mejoras del sitio web

Nuestro nuevo sitio web https://Ecosystem.Support/ ¡esta creciendo! Comenzamos poco a poco con una sección de preguntas frecuentes y algunos cambios en la página principal; seguiremos con un escaparate de subvenciones y un blog dedicado para actualizaciones periódicas.

No queremos que se desperdicien valiosas habilidades, por lo que hemos renovado nuestros formularios de consulta para que sean un poco más abiertos, incluido un camino dedicado para las personas que están interesadas en contribuir al ecosistema pero aún no están seguros de dónde encajan. ¡Siéntase libre de echar un vistazo y aplicar!

Ewasm

Escrito por Alex Beregszaszi y Paul Dworzanski

Desde la última actualización, el enfoque del equipo Ewasm se ha desplazado hacia la investigación sobre Eth 2.0, trabajando en estrecha colaboración con otros equipos.

A medida que se acerca el lanzamiento de la fase 0 de Eth 2.0, la capa de ejecución de la fase 2 se encuentra en desarrollo activo, en paralelo con el desarrollo de las fases 0 y 1. Se han hecho múltiples propuestas para la arquitectura de la fase 2. El equipo de Ewasm ha estado trabajando en Diseños informativos con prototipos y puntos de referencia, construidos sobre una base mínima en Scout.

Explorar

los Especificación Scout es una interfaz mínima para EE (entornos de ejecución). Esta interfaz mínima es suficiente para crear prototipos de EE sin estado, que son necesarios para validar el modelo sin estado y para informar el diseño de Ewasm y la fase 2.

Scout tiene tres implementaciones:

  • explorar en Rust, diseñado para la creación rápida de prototipos y colaboración (utiliza un intérprete Wasm con soporte para la creación de perfiles),

  • scout.ts en Typecript para la creación rápida de prototipos y el soporte del navegador,

  • y ScoutOne en C ++, diseñado para uso de rendimiento y producción, para ser incrustado por clientes Eth 2.0.

Entornos de ejecución

A diferencia del modelo de estado Eth 1 que tiene problemas de escala conocidos, Eth 2 se propone sin estado, donde el estado se almacena fuera de la cadena, y solo un hash que representa el estado se almacena en la cadena, con testigos pasados ​​como parte de las transacciones.

El modelo sin estado presenta nuevos desafíos. Se necesitan prototipos y mediciones para validar su viabilidad.

El equipo de Ewasm ha puesto un gran esfuerzo en la creación de prototipos y la medición de EE sin estado, que clasificamos de la siguiente manera:

  1. Un EE que debe ser compatible con las estructuras de datos Eth 1 y su ejecución.

    • SMPT (Stateless Merkle Patricia Trie) usando RLP para serializar los datos de testigos y transacciones, y usando el esquema de firma Eth1.

    • Una implementación de EVM en Assemblyscript.

    • biturbo (anteriormente conocido como TurboToken), que usa Multiproof para codificar de manera más eficiente los datos de testigos y también admite la ejecución de EVM.

  2. Diseños sin necesidad de compatibilidad con versiones anteriores.

    • Token KMM (Katajainen Makinen Merkle) EE que está optimizado para el tamaño del testigo y el tiempo de ejecución.

    • Implementación del verificador Groth16 para soportar zk-SNARK dentro de Eth 2.

    • Implementación del verificador STARK.

De notable interés es la investigación activa en la interacción entre las cadenas Eth 1 y Eth 2. Para ayudar a la evaluación de la propuesta de "cambio", donde Eth 1 se traslada a un EE en Eth 2, los Eth 1 EE mencionados anteriormente fueron prototipados. El equipo también está evaluando activamente las propuestas que unen las dos redes y sus implicaciones en el diseño de EE.

Nuestro objetivo final es proporcionar una buena experiencia de desarrollador para DApps existentes y nuevos.

Este trabajo de EE ha estado retroalimentando el diseño de Scout y Eth 2.

Criptografía rápida

Para que Ewasm tenga éxito, debemos ejecutar cripto costoso en cadena. Afortunadamente, la criptografía a menudo tiene cuellos de botella en tiempo de ejecución en aritmética bigint. Primero hemos comparado varias implementaciones de primitivas criptográficas para identificar cuellos de botella. Luego, diseñamos una API bigint nativa rápida para abordar estos cuellos de botella. Finalmente aumentamos el altamente optimizado telaraña biblioteca, en colaboración con sus creadores, para llamar a esta API bigint.

Los resultados son alentadores: con esta API bigint implementada en intérpretes, nos acercamos a las velocidades nativas en las operaciones de curva elíptica (!), Que son bloques de construcción para muchas criptomonedas. Ahora podemos ejecutar emparejamientos a velocidades casi nativas. Esta es la mayor historia de éxito reciente de Ewasm.

Este trabajo ha permitido que los prototipos EE anteriores operen dentro de las limitaciones de rendimiento de Eth 2.

Velocidad, Medición, Tamaño

Ewasm tiene muchos otros proyectos relacionados con la velocidad, la medición (lo que reduce la sobrecarga de tiempo de ejecución de medición y la aproximación precisa del tiempo de ejecución) y el tamaño del código de bytes. Desde la optimización del motor Wasm hasta el análisis de medición y las transformaciones de bytecode, el equipo de Ewasm está trabajando arduamente para diseñar el mejor sistema de ejecución posible.

Estampación

Estamos trabajando continuamente en herramientas para Ewasm.

Se proporcionan enlaces para las API Eth 2 y bigint Asamblea y Moho.

Si un bytecode Wasm requiere aumento, una herramienta extensible llamada cincel está desarrollado para proporcionar diversas transformaciones (como la reducción del tamaño del código de bytes y los ajustes de las importaciones / exportaciones) que necesitan tanto los casos de uso Ewasm como los que no son Ewasm.

Verificación formal

Escrito por Leo Alt

El nuevo equipo de Verificación formal está trabajando en herramientas, apoyando a otros equipos de la Fundación con modelos y pruebas formales, y combinando esfuerzos con miembros de la comunidad Ethereum FV.

Específicamente, el trabajo reciente se ha centrado en:

  • SMTChecker de Solidity, un verificador de modelo ilimitado para contratos inteligentes de Solidity.

  • La semántica de KYul, Yul en K. KYul se utiliza además para admitir el compilador Solidity al calcular pruebas de bisimulación para código Yul no optimizado y optimizado.

  • Liderando el desarrollo de un lenguaje de especificación de contrato inteligente con el apoyo de varios miembros de la comunidad FV. El lenguaje de especificación, utilizado para describir las propiedades del contrato, pretende ser simple y compatible con muchas herramientas de FV.

  • Apoyando al equipo de investigación Eth2 y la verificación de tiempo de ejecución en los esfuerzos de verificación de Beacon Chain.

  • Mantener HEVM (junto con Dapphub), una implementación de Haskell EVM totalmente compatible.

  • Apoyar al equipo de pruebas extendiendo la cobertura de las pruebas de Ethereum con los vacíos descubiertos en diferentes implementaciones de EVM.

Geth

Escrito por Péter Szilágyi

Con el lanzamiento de v1.9.0 en julio, el equipo de Geth ha estado mayormente ocupado iterando en la base de código existente; arreglando cualquier problema descubierto; y preparando al cliente para el hard fork de Estambul. Además de estos cambios de mantenimiento, con un total de 8 lanzamientos, el equipo también ha estado sentando las bases para algunas cosas nuevas por venir.

Hemos creado un tesoro de 5 EIP que giran en torno a los ENR (Ethereum Node Records) para ser utilizados en redes y descubrimiento de pares. Con la ayuda de estos, los nodos Geth se han ampliado gradualmente para anunciar mucha más información sobre ellos mismos que los protocolos existentes permitidos (direcciones IPv4 e IPv6, afiliación a la red Ethereum, bifurcaciones configuradas y aplicadas, capacidades de servidor ligero, etc.). El trabajo de identificación de fork ya se ha implementado sobre el protocolo eth, lo que permite que los nodos Geth particionen limpiamente la red entre máquinas incompatibles. Los registros también están siendo indexados por un nuevo servicio de descubrimiento expuesto sobre DNS (aún no finalizado), lo que hace que los ataques de eclipse sean exponencialmente más difíciles y permitirá que Ethereum se ejecute en entornos donde UDP está bloqueado (DNS sobre HTTPS).

En cuanto al rendimiento, estamos trabajando en múltiples frentes. En un extremo del espectro, estamos tratando de reducir la carga en la red haciendo que las transacciones (y tal vez incluso los bloques) se propaguen de manera más inteligente; mientras que en el otro extremo estamos trabajando en una instantánea de estado que puede seguir la cadena en vivo y actuar como una estructura de aceleración para la ejecución de EVM, así como la sincronización de estado. Mientras tanto, estamos trabajando en varias opciones de configuración para Geth que permitirían a los usuarios descartar partes de la base de datos que no les sean útiles (sin afectar el estado de la red), ahorrando una preciosa capacidad de SSD. Todos estos son caminos prometedores y compartiremos algunos números en el futuro cercano.

También se invirtió una gran cantidad de trabajo en la infraestructura ligera del cliente, lo que permitió a los operadores del servidor asignar y administrar las prioridades del cliente y las asignaciones de recursos a través de la API RPC. Si bien a largo plazo, la incentivación liviana del cliente está planificada para funcionar a través del protocolo de igual a igual, el conjunto de características actual ya permite a un operador recolectar pagos fuera de Geth y sincronizarlos con la contabilidad interna de Geth. Esto debería permitir inmediatamente a cualquiera crear un servicio de servidor ligero pagado (aunque tenga en cuenta que esto está en una fase de prototipo). Actualmente se está trabajando hacia la capa de pago P2P.

Equipo Javascript

Escrito por: Samuel Furter, Holger Drewes, Marc Garreau, Everton Fraga, Richard Moore

Es posible que ya lo haya escuchado, ya que no era un secreto, pero aprovechará este Informe EF Dev para anunciar oficialmente: EF ha formado un nuevo y poderoso equipo de JavaScript que reúne los siguientes proyectos bien establecidos bajo un mismo techo:

Las personas de estos diferentes equipos ya han comenzado a contribuir a través de líneas de proyecto y para discutir temas de interoperabilidad y esperamos que se desarrollen fuertes sinergias en el futuro a medio plazo. Utilizamos este primer trimestre como un nuevo equipo para crecer juntos, generar confianza y establecer las estructuras organizativas necesarias. Espere escuchar más en 2020 cuando presentaremos y ejecutaremos una estrategia y visión coherentes para maximizar nuestro impacto para apoyar el ecosistema de desarrolladores Ethereum JavaScript / TypeScript (está muy invitado a Únete a la discusión) Esto irá más allá del alcance de los antiguos proyectos individuales.

Sin embargo, los proyectos actuales no serán olvidados. Somos muy conscientes de que debemos cuidar y desarrollar aún más las herramientas que se utilizan ampliamente en la comunidad. Aquí están las actualizaciones respectivas para arrojar algo de luz sobre lo que sucedió dentro de estos proyectos durante el último trimestre.

Web3.js

Hemos lanzado múltiples parches para Web3.js desde la última publicación del blog de EF y cambió a versiones semánticas. Esos parches agregaron compatibilidad con TypeScript, ampliaron las funcionalidades de firma de transacciones, agregaron las propiedades del flujo de trabajo de confirmación de transacciones, agregaron el método JSON-RPC de larga data getChainId, agregó el conectado evento a las suscripciones, extendió la interfaz del proveedor con el método suscripciones y funciones de utilidad adicionales para trabajar con filtros de floración.

Se pueden ver más detalles sobre las nuevas funciones y mejoras en nuestros anuncios de lanzamiento en GitHub.

Actualmente, estamos enfocados en reducir el tamaño del paquete, mejorar el rendimiento y agregar reconexión para WebsocketProvider, y mejorando el TypeScript DX.

Además de todas estas grandes mejoras, también tuvimos la oportunidad de dar la bienvenida Chris al equipo EF-JS. Chris actualmente apoya Web3.js desarrollo, pero también participará en todos los demás paquetes EF-JS.

Ethers.js

Hemos estado recibiendo v5 listo para el consumo público, y la adopción ha ido creciendo constantemente. Muchísimas gracias a todos por probarlo y reportar problemas.

El enfoque en v5 ha sido agregar extensibilidad y mejorar la API para desarrolladores de framework, incluyendo un nuevo framework, ethers-app, con un enfoque en desarrolladores de dapp.

Dado que la cantidad de nuevos problemas ha disminuido, esperamos lanzar v5 a producción muy pronto, con solo algunos pequeños cambios en la tubería y un par de nodos restantes en la documentación completamente renovada.

EthereumJS

Lo más notable en el EthereumJS lado están los lanzamientos de los diferentes componentes de orientación Estanbul soporte: la VM se ha vuelto más grande v4.1.0 actualizar en septiembre y actualmente estamos planchado los últimos errores para hacer que la VM sea totalmente compatible con el conjunto de pruebas oficial. Otras actualizaciones que se mencionarán en el Estanbul contexto son los lanzamientos en el transacción, bloquear y común (hardfork y lógica de red) bibliotecas.

Cuadrícula

Desde la última actualización de la publicación del blog de EF, se realizaron varias actualizaciones importantes para Rejilla Ethereum. La aplicación ahora vive en la barra de tareas de su sistema operativo y proporciona una interfaz de usuario simple para descargar, configurar y ejecutar clientes y herramientas de Ethereum. El sistema de complementos continúa perfeccionándose con cada nueva integración, pero igualmente interesantes son las aplicaciones Grid. Se han puesto a disposición aplicaciones para probar métodos RPC, consultar datos de bloque a través de la implementación GraphQL de Geth, firmar transacciones con Clef y más. El equipo ha estado ocupado escribiendo tutoriales sobre lo que puede hacer con Grid, que puede encontrar en el Publicación mediana.

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

Escrito por Piper Merriam

Web3.py

El trabajo reciente ha sido hacia una mejor estabilidad y documentación. El enfoque actual es agregar soporte asíncrono para la biblioteca.

Trinidad

El cliente Trinity está trabajando para una versión beta que incluiría el "Beam Sync" recientemente desarrollado (https://medium.com/@jason.carver/intro-to-beam-sync-a0fd168be14a). También nos estamos centrando en los esfuerzos de colaboración con el ecosistema más amplio de equipos de clientes para tratar de abordar algunos de los problemas más grandes como la hinchazón estatal y descubrir una ruta de migración para Eth 1.x hacia el mundo 2.0.

EthPM

Seguimos centrándonos en las herramientas del ecosistema. los ethpm-cli continúa mejorando permitiendo la instalación de paquetes de varias fuentes, así como la construcción y publicación de paquetes.

Remezcla

Escrito por Yann Levreau

Con respecto a Remix, tenemos muchas actualizaciones para compartir. En los últimos meses, nuestro equipo ha estado trabajando:

  • Mejorando Remix Plugin y trabajando con las comunidades de varias maneras: @GrandSchtroumpf.

  • Implementación de un complemento de WebSocket para la integración de github de Edi Sinovcic.

  • Ayuda a Quorum a integrar sus complementos Remix.

  • Trabaja con Waffle (Ethworks) en sus complementos.

  • Trabaje con el equipo de VSCode ethereum para integrar el motor de complementos como una extensión de VSCode.

  • Cambie los recursos del complemento de carga para que estén completamente descentralizados (IPFS por el momento).

  • Remix bibliotecas: @Aniket se unió al equipo recientemente para mejorar, mantener y promover el repositorio de bibliotecas remix https://github.com/ethereum/remix. Eso incluye el trabajo crítico en remix-debug (depuración de transacciones), remix-tests, remix-solidity, remix-analyzer (nuevo módulo agregado: advertencia de transferencia de ether en bucle)

  • Bibliotecas Remix: finalizando remix-simulator y agregando más pruebas a remix-debug @iurimatias

  • Mejora del explorador de archivos del IDE para admitir carpetas y funciones estándar. Trabajando con Ethworks en nuevos temas. Usando el editor de Mónaco. Establecer la versión del compilador según el pragma Solidity – @Lianahus @ryestew @Aniket @GrandSchtroumpf

  • Presentamos el escritorio Remix aquí https://medium.com/remix-ide/remix-desktop-8c1e9e946ee1, y ahora lo estamos finalizando. ¡Esté atento a un lanzamiento muy pronto! – @ yann300 @lianahus

  • Remix Workshop es un complemento que se ejecuta dentro de la API del complemento Remix.

Permite la creación de tutoriales, el registro de tutoriales, y que los estudiantes y los alumnos prácticamente ejecuten tutoriales. El alcance de los tutoriales que se realizan es muy amplio (Solidez, Vyper, concepto general de Etherum, etc.). ¡Depende de los creadores de tutoriales! El primer POC fue exitoso y ahora estamos avanzando hacia el lanzamiento de una primera versión con la ayuda de diferentes equipos de la comunidad para recibir asesoramiento y comentarios. – @GrandSchtroumpf @ryestew

  • Talleres y divulgación más allá de la comunidad: un aspecto de nuestro trabajo es también contribuir en el esfuerzo educativo de varias maneras. Esperamos que esto tenga más importancia en 2020. – @ryestew @Aniket @GrandSchtroumpf @team

  • Organizar talleres / reuniones (ESCE, Consensys, Devcon, Dappcon).

  • Reúnase con organizaciones y personas de fuera de la comunidad. No necesariamente para incorporarlos técnicamente, sino más para dar una primera impresión de lo que es blockchain, ethereum y más.

  • Construya prácticamente una herramienta para eso (vea el taller Remix)

Investigación (CBC)

Escrito por Aditya Asgaonkar

Para el equipo Casper CBC, nuestro enfoque últimamente ha sido:

  1. Describiendo el protocolo mínimo CBC Casper junto con estrategias de validación para la vida en un marco unificado (denominado Sistema de producción de mensajes y transición de estado etiquetado válido, VLSM). El documento público es WIP, se lanzará pronto.

  2. Verificación formal de VLSM

  3. Uso de elementos CBC Casper para mejorar el diseño Eth2.0, como https://ethresear.ch/t/cross-shard-messaging-system/6201

  4. Esfuerzos de alcance comunitario como este AMA: https://www.reddit.com/r/ethereum/comments/dsiz9j/ama_we_are_the_cbc_casper_research_team/

¡Mantente sintonizado para escuchar más!

Investigación (plasma)

Escrito por Plasma Group

Desde mayo, hemos estado trabajando arduamente para avanzar en la tecnología de escalado. Hay 4 equipos diferentes en el ecosistema que desarrollan la especificación de plasma generalizado para múltiples blockchains, incluidos OmiseGO, Matic, Cryptoeconomics Lab y Plasm. Como muchos de nuestros pares están trabajando arduamente en los pagos de producción, comenzamos a buscar áreas de escalado ligeramente menos investigadas, como el desarrollo de aplicaciones y la capacidad de compilación general. Los desarrollos en este frente incluyen la Optimistic Virtual Machine, un lenguaje de disputa universal para las construcciones de capa 2, así como nuestra demostración con Uniswap para Devcon5, un juego de intercambio y pagos escalables que se puede encontrar en Unipig Exchange. El juego se basa en una cadena de acumulación optimista, un diseño que surgió de las conversaciones con Barry Whitehat y Vitalik en la conferencia Scaling Ethereum a principios de junio.

A medida que concluimos el fin de año, nos estamos preparando para sacar un documento para el OVM, así como para escribir más documentación en profundidad para Optimistic Rollup. Por ahora, aquellos que estén interesados ​​en conocerlo pueden encontrar una descripción en nuestro blog donde describimos cómo construirlo para contratos inteligentes arbitrarios, junto con una documentación temprana que describe el camino desde el plasma hasta el resumen optimista en:

Nuestro foro: https://plasma.build/t/rollup-plasma-for-mass-exits-complex-disputes/90/1

En Github: https://gist.github.com/karlfloersch/1bf6ab7871f41e3a5a921c0a007ad5c6

Llamada de plasma: https://youtu.be/5RpYoU6xD_M?t=1136

Investigación (Serenity / Eth2)

Escrito por EF Team

Después de Devcon5, Danny y el equipo de investigación de Eth2 comenzaron a trabajar en una serie semanal de actualizaciones rápidas de Eth2, y recientemente en una serie centrada en la validación en Eth2. Para conocer las últimas noticias y avances a medida que nos acercamos al lanzamiento de la Fase 0, consulte los enlaces a continuación y manténgase atento a Blog de EF!

En general, el progreso continúa hacia las pruebas de fase 0 y el lanzamiento de la red principal. Las especificaciones y los prototipos de la Fase 1 se mueven en paralelo, mientras que la Fase 2 continúa la I + D activa y fructífera.

Validado: Apuesta en Eth2 # 0 – 2019-11-27

Eth2 Actualización rápida # 4 – 2019-11-21

Eth2 Actualización rápida # 3 – 2019-11-08

Eth2 Actualización rápida # 2 – 2019-10-31

Eth2 Actualización rápida # 1 – 2019-10-23

Seguridad (pruebas de seguridad / consenso)

Escrito por Martin Holst Swende

Por el lado de la seguridad, ha habido mucha acción con respecto a la bifurcación de Estambul. El viejo fuzzer basado en pitón (Evmlab) ha sido reescrito en Go, y se ha utilizado para crear fuzzers dirigidos a EIP. Estos fuzzers se han usado para generar casos de prueba (encontrando fallas de implementación tanto en Besu como en Nethermind) y se usaron para ejecutar millones de casos de prueba comparando Geth y Parity, y a fines de noviembre, también teníamos máquinas virtuales Aleth y Nethermind ejecutándose en el mismo marco de fuzzer. ¡Así que ahora tenemos hasta cuatro EVM haciendo difuminado diferencial!

Mientras tanto, también estamos ejecutando fuzzers basados ​​en libfuzzer en Geth y Parity, un esfuerzo que está siendo liderado por @cryptomental.

Hace un tiempo, se anunció en la página de Bounty que $ 15K USD se asignaron a auditorías de seguridad de EIP. Fuera de esto, hemos otorgado $ 5K cada uno a Neville Gretch contract-library.com y Hubert Ritzdorf (Chainsecurity) por su trabajo ayudando a evaluar el impacto de seguridad de EIP-1884.

Se han otorgado varias otras recompensas, la mayoría de las cuales se compartirán públicamente pronto.

Solidez

Escrito por Christian Reitwiessner

El lenguaje y compilador de Solidity continúa estabilizándose y agregando características solicitadas por la comunidad. Estas incluyen opciones para generar el código de Solidez para su uso en una variedad de formatos flexibles, cambios de estabilidad y seguridad. El equipo está trabajando en una nueva versión 0.6.0, así como en actualizaciones para la versión 0.5.x brach.

Montaje web

Solidity admite la salida de vista previa experimental del código de ensamblaje web mediante el interruptor –ewasm. Extendimos la mayoría de las etapas del optimizador Yul para hacer frente al código eWasm, estamos trabajando en el código de pegamento que traduce Yul con sabor EVM a Yul con sabor eWasm y tenemos un prototipo funcional para la generación de código binario eWasm que se necesita para implementar contratos.

Solidez 0.6.0

Casi hemos terminado con la implementación de cambios importantes y esperamos lanzar Solidity 0.6.0 a finales de este año. Algunos de los nuevos cambios incluyen:

  • Requerir palabras clave "virtuales" y "anular" explícitas para anular funciones.

  • ABIEncoderV2 ya no es experimental.

  • Una función de reserva se divide en una función de "recepción de éter" y una función de "reserva" real.

  • Los contratos abstractos deben (y pueden) marcarse como "abstractos".

  • Las estructuras y enumeraciones se pueden definir a nivel de archivo.

  • No permita establecer la longitud de una matriz de almacenamiento de forma arbitraria.

  • Admite push () para agregar un nuevo elemento inicializado por defecto a la matriz de almacenamiento dinámico.

  • Agregue la declaración "leave" a Yul / Inline Assembly para regresar de la función actual.

  • Admite múltiples valores de retorno en NatSpec.

  • Mejor formato de mensaje de error en la línea de comandos.

  • El hash de metadatos ahora es IPFS de forma predeterminada y se puede cambiar a Enjambre o eliminar.

  • Permitir que se eliminen las "cadenas de razón de reversión" del binario.

SMT Checker

El SMTChecker tiene un nuevo motor de verificación de modelos que admite bucles y permite verificar aserciones considerando un número ilimitado de transacciones. Lea más información sobre los cambios aquí: https://medium.com/@leonardoalt/smtchecker-toward-completeness-1a99c02e0133.

Actualmente estamos trabajando para admitir llamadas de función en el nuevo motor, lo que permitirá el análisis de contratos múltiples incluso cuando se desconoce el código llamado.

Yul Optimizer

El optimizador de Yul ahora puede tener en cuenta la ausencia de efectos secundarios de las funciones definidas por el usuario y, por lo tanto, optimizar a través de dichas llamadas de función. Es capaz de eliminar llamadas sload y mload redundantes y puede tener en cuenta valores locales condicionales de variables.

Interfaz del compilador:

  • Si se usa standard-json, el compilador solo genera bytecode para el contrato seleccionado o se detiene después de analizar y analizar si no se solicita bytecode.

  • La opción –error-recovery se puede usar para recuperarse de la mayoría de los errores del analizador para que pueda crear algo así como un AST también para una entrada no válida.

Además de los cambios enumerados anteriormente, implementamos numerosas correcciones de errores y características pequeñas.

State Channel Research

Escrito por Liam Horne

En los últimos meses, la comunidad de I + D de los canales estatales de Ethereum ha progresado rápidamente.

Lo más emocionante es que los canales estatales están en vivo en mainnet. Connext, un servicio de micropagos construido sobre nuestro trabajo, ha estado funcionando en producción desde septiembre de 2019. La escalabilidad y las mejoras de UX que brindan los canales estatales ya no son teóricas, ahora están beneficiando a los usuarios. ¡Ve a probarlo!

Detrás de escena, I + D ha estado ocupado durante los últimos 6 meses. Este verano, los dos grupos principales de investigación de canales estatales, Counfactual y Magmo, unificaron su trabajo en un solo proyecto y protocolo, simplemente llamado "StateChannels". Esta unificación nos ha permitido avanzar a un ritmo más rápido y también proporcionar una experiencia más fácil para los desarrolladores de aplicaciones de Ethereum, que no necesitan pensar en qué canales estándar tienen la intención de admitir.

Más específicamente, en los últimos meses tenemos:

¿Qué sigue para los canales estatales?

  • Estamos trabajando en 2 aplicaciones de demostración, construidas completamente sobre la API del cliente y se ejecutan en el navegador a través de nuestro centro de referencia.

  • Incorporar nuevos proyectos, reclutar nuevos contribuyentes y continuar haciendo que los canales estatales sean extremadamente amigables para los desarrolladores.

ZoKrates

Escrito por Jacob Eberhardt

Nos complace compartir una nueva actualización significativa sobre el progreso para hacer de ZoKrates un kit de herramientas potente y fácil de usar para zkSNARKs en Ethereum.

Grandes noticias para los desarrolladores de ZoKrates: el desarrollo en el navegador del código de ZoKrates ahora es compatible con Remezcla. Puede encontrar el complemento ZoKrates a través del administrador de complementos en la pestaña izquierda.

Una solicitud de larga data era un sistema de tipos más rico, y con nuestro último lanzamiento, enviamos exactamente eso: ZoKrates ahora admite tipos complejos definidos por el usuario en forma de estructuras, así como matrices multidimensionales. Para permitir una interacción perfecta con los programas de ZoKrates que utilizan estos nuevos tipos del mundo exterior, hemos agregado un JSON-ABI, que permite un fácil acceso programático.

En un esfuerzo por hacer que ZoKrates sea más legible, reestructuramos nuestro sistema de módulos y cambiamos las terminaciones de archivos de código fuente de ZoKrates a .zok. Internamente, la reinstalación del analizador basada en una gramática DSL formal, mencionada en nuestra última publicación de actualización, se completó con éxito.

Finalmente, se introdujeron más optimizaciones en los programas compilados para reducir la ejecución y el tiempo de generación de pruebas. ¡Para educar a la comunidad, presentamos estos resultados y las aplicaciones que utilizan ZoKrates en Devcon V en Osaka!

Fuente: https://blog.ethereum.org/2019/12/03/ef-supported-teams-research-and-development-update-2019-pt-2/