Saltar al contenido

Los archivos 1.x: resumen de llamadas de diciembre

17 de diciembre tl; dc (demasiado tiempo, no llamé)

Renuncia: Este es un resumen de los temas discutidos en la llamada de investigación recurrente Eth1.x, y no representa planes ni compromisos finalizados para las actualizaciones de la red.

El tema principal de discusión para esta convocatoria y la investigación más amplia de Eth1.x es la viabilidad de clientes apátridas. Esta semana se trató en gran medida de organizar y evaluar los diversos desafíos que el concepto de cliente apátrida deberá superar para ser viable e identificar algunos objetivos tangibles a corto plazo (3 a 6 meses) en los que centrarse.

En el lado logístico:

  • En este punto, no hay suficiente contenido compilado para garantizar la creación de un repositorio de especificaciones Eth1x, pero el establecimiento de un repositorio público para la investigación continua será revisado en la próxima convocatoria / reunión.

  • El grupo de trabajo Eth 1.x tendrá como objetivo celebrar ~ 3 reuniones en persona el próximo año, con la primera planeada tentativamente junto a EthCC, pero como Francia todavía está en huelga, esto aún es incierto.

  • La próxima llamada está programada tentativamente para mediados de enero de 2020. Como siempre, si está interesado en unirse a la llamada o al grupo de telegramas, Por favor presentarte en los foros de ethresearch.

  • Un área en la que se está enfocando el grupo de trabajo es mantener un alto nivel de comunicación con la comunidad más amplia de Ethereum. Esto incluye hablar y responder preguntas en las muchas conferencias de Ethereum en 2020, pero también incluye explicadores y estas actualizaciones de llamadas. Si tiene comentarios sobre las comunicaciones Eth 1.x, desea encontrar un orador para un próximo evento o tiene alguna pregunta, comuníquese con @gichiba o @JHancock en Twitter o en los foros de ethresearch.

Discusión técnica:

  • La apatridia es un espectro. Sería casi imposible diseñar e implementar un cambio de red que haría todos los nodos en Ethereum cambian a un paradigma sin estado. Más bien, debería ocurrir algo menos dramático: se pueden desarrollar nuevas primitivas de red que permitan una gama de comportamientos con estado / sin estado; con los mineros y los nodos de archivo que permanecen en "estado completo", mientras que los clientes y los nodos específicos de dapp pueden optar por mantener un estado parcial o estar completamente sin estado.

  • Hay una serie de problemas que deben considerarse para que esto funcione:

    • Preguntas sobre los incentivos para mantener el estado total o parcial, y qué efecto tienen esos incentivos en la topología general de la red. Por ejemplo, debe existir un incentivo para que un minero de todo el estado incluya datos de testigos en cada bloque, y un incentivo para verificar testigos en los bloques recibidos. En términos más generales, parece que una red semiestatal naturalmente se organizaría como el diagrama a continuación, con mineros de estado completo que pasan y verifican nuevos bloques hacia afuera para clientes de estado parcial, que aún pueden proporcionar testigos para los clientes apátridas en los bordes (confiando enteramente en testigos). Esto no es algo bueno o malo, pero las implicaciones de una topología como la que se muestra a continuación deben considerarse plenamente.

    • El formato del testigo aún no se ha definido formalmente. Optimistamente, el formato para los testigos se presentaría en el mismo molde que la sincronización de la reina roja protocolo para el estado y la semántica de los testigos formalizados como tales. Hay una gran ventaja en una definición más formal de testigos en el contexto del desarrollo del cliente, y de hecho, el equipo de turbogeth espera tener testigos formalizados a principios del próximo año. Los testigos de bloque y su propagación son esenciales para avanzar hacia el concepto de cliente apátrida.

    • En el corto plazo, la sincronización de haz de Trinity implementa una versión limitada de testigos estatales, y es un buen primer paso hacia los testigos en la red principal. La sincronización del haz no es específicamente un precursor para la investigación de clientes sin estado (más bien, es una mejora de UX para Eth 1.0), pero puede verse como una oportunidad para la experimentación de redes con propagación de testigos, especialmente implementaciones entre clientes. Actualmente Besu está experimentando con su propio prototipo de sincronización de haz. Un objetivo tangible para el corto plazo es obtener una especificación de prueba común para la sincronización entre clientes, lo que ayudará con la recopilación de datos más adelante. Esto suena como un trabajo para Colmena. Tal como están las cosas, la sincronización de haces está planificada para estar lista para el horario estelar (pasar testigos de manera confiable) en el segundo trimestre del próximo año.

    • Hay complejidades en torno al tamaño de los gases y los testigos que deben abordarse para que los clientes apátridas sean viables. Se cree que la propuesta "unGas" de Wei Tang es una solución potencial, pero a pesar de que no es particularmente complicado de implementar dentro de Ethereum, existen efectos indirectos (como cambios necesarios en los compiladores, posibles efectos de contratos inteligentes, etc.) que complican la implementación. Todo esto aún no se ha investigado a fondo.

  • El objetivo más amplio con esta discusión es enfocar y organizar el trabajo a corto plazo. Esto significa priorizar el trabajo en la especificación / implementación de testigos, comenzar a delinear algunas pruebas estándar para la sincronización entre clientes y recopilar más datos sobre los requisitos de red de modelado para la propagación de testigos.

Fuente: https://blog.ethereum.org/2019/12/20/eth1x-files-digest-no-1/