Geth v1.9.0

Después de muchos meses de silencio, ¡estamos orgullosos de anunciar el lanzamiento v1.9.0 de Go Ethereum! A pesar de que esta versión lleva más tiempo de lo que anticipamos, estamos seguros de que habrá algunas características jugosas para que todos disfruten.

Advertencia: hemos hecho todo lo posible para eliminar todos los errores, pero al igual que con todas las versiones principales, aconsejamos a todos que tengan mucho cuidado al actualizar. La versión v1.9.0 contiene cambios en el esquema de la base de datos, lo que significa que no es posible degradar una vez que se actualice. También recomendamos una nueva sincronización rápida, ya que puede reducir drásticamente el tamaño de la base de datos.

Algunas de las características mencionadas aquí se han enviado de forma silenciosa a lo largo de la familia de versiones 1.8.x, pero las hemos considerado lo suficientemente importantes como para resaltarlas explícitamente.

Es interesante darse cuenta de que la sección "Rendimiento" estaba en algún lugar al final de los anuncios anteriores, pero con los años se convirtió en una de las mejoras más buscadas.

En los últimos 6 meses, hemos tratado de analizar los diferentes componentes que se encuentran en la ruta crítica del procesamiento de bloques, en un intento por identificar y optimizar algunos de los cuellos de botella. Entre las muchas mejoras, las de mayor impacto fueron:

• El descubrimiento y la optimización de una CPU cuadrática y la complejidad de la E / S del disco, originada en la implementación Go de LevelDB. Esto hizo que Geth se muriera de hambre y se paralizara, empeorando exponencialmente a medida que la base de datos crecía. Un enorme saludo a Gary Rong por sus incansables esfuerzos, especialmente porque su trabajo es beneficioso para toda la comunidad de Go.
• El análisis y la optimización de los patrones de acceso de la cuenta y el almacenamiento a través de los bloques. Esto resultó en la estabilización del uso de la memoria de Geth incluso durante la importación de los bloques DoS de Shanghai y en la aceleración del procesamiento general de bloques mediante la captura previa del estado heurístico concurrente. Este trabajo fue realizado principalmente por Péter Szilágyi.
• El análisis y la optimización de varios códigos de operación de EVM, con el objetivo de encontrar valores atípicos tanto en la implementación de EVM de Geth como en el diseño del protocolo de Ethereum en general. Esto llevó tanto a correcciones en Geth como a inflexiones en las discusiones de escalamiento de Eth 1.x. Shoutout va a Martin Holst Swende por ser pionero en este esfuerzo.
• El análisis y la optimización de los esquemas de nuestra base de datos, tanto para eliminar los datos redundantes como para rediseñar los índices para un menor uso del disco (a veces, a costa de un pequeño impacto de la CPU). Los apoyos para estos esfuerzos (que abarcan de 6 a 9 meses) van para Alexey Akhunov, Gary Rong, Péter Szilágyi y Matthew Halpern.
• El descubrimiento de una sobrecarga de compactación LevelDB durante la fase de sincronización de estado de la sincronización rápida. Al asignar temporalmente los cachés de poda a las floraciones de sincronización rápida, hemos podido provocar un cortocircuito en la mayoría de los accesos de datos en memoria. Este trabajo fue realizado principalmente por Péter Szilágyi.

(TL; DR) Sincronización rápida

Hemos ejecutado un punto de referencia de sincronización rápida en dos i3.2xlarge Instancias de AWS EC2 (8 núcleos, 61 GiB RAM, 1.9 TiB NVMe SSD) con --cache = 4096 --maxpeers = 50 (por defecto en v1.9.0) el 25 de abril.

(TL; DR) Sincronización completa

Hemos ejecutado un punto de referencia de sincronización completo en dos i3.2xlarge Instancias de AWS EC2 (8 núcleos, 61 GiB RAM, 1.9 TiB NVMe SSD) con --cache = 4096 --maxpeers = 50 --syncmode = full.

* Si bien el rendimiento es similar, lo logramos al mismo tiempo que reducimos el uso de la memoria en aproximadamente 1/3 y eliminamos por completo los picos de memoria falsos (Shanghai DoS). El motivo de la mayor E / S del disco se debe a que utiliza menos memoria para el almacenamiento en caché, ya que tiene que empujar más agresivamente al disco.

(TL; DR) Archivo sincronizado

Hemos ejecutado una referencia de sincronización de archivos en dos m5.2xlarge Instancias de AWS EC2 (8 núcleos, 32 GiB RAM, 3TiB EBS SSD) con --cache = 4096 --syncmode = completo --gcmode = archive.

* Los volúmenes de EBS son significativamente más lentos que los SSD físicos conectados a la VM. Se puede lograr un mejor rendimiento en máquinas virtuales con SSD reales o hardware físico real.

¿No sería asombroso si no tuviéramos que desperdiciar tanto espacio precioso en nuestros costosos y sensibles SSD para ejecutar un nodo Ethereum, y podríamos mover al menos parte de los datos a un disco duro barato y duradero?

Con la versión v1.9.0, Geth separó su base de datos en dos partes (hechas por Péter Szilágyi, Martin Holst Swende y Gary Rong):

• Los bloques recientes, todas las estructuras de estado y aceleraciones se guardan en un almacén rápido de clave-valor (LevelDB) como hasta ahora. Está diseñado para ejecutarse sobre un SSD, ya que el rendimiento de ambos E / S de disco es crucial.
• Los bloques y recibos que son más antiguos que un umbral de corte (3 épocas) se mueven de LevelDB a una costumbre congelador base de datos, que está respaldada por un puñado de archivos planos solo de apéndice. Como el nodo rara vez necesita leer estos datos, y solo se agrega a ellos, un disco duro debería ser más que adecuado para cubrirlos.

Una nueva y rápida sincronización en el bloque 7.77M colocó 79 GB de datos en el congelador y 60 GB de datos en LevelDB.

Fundamentos del congelador

Por defecto, Geth colocará su congelador dentro de su chaindata carpeta, en el antiguo subcarpeta La razón para usar una subcarpeta era evitar romper cualquier herramienta automatizada que pudiera estar moviendo la base de datos alrededor o entre instancias. Puede colocar explícitamente el congelador en una ubicación diferente a través de --datadir.anciente Bandera de la CLI.

Cuando actualice a v1.9.0 desde una versión anterior, Geth migrará automáticamente los bloques y recibos de la base de datos de LevelDB al congelador. Si no has especificado --datadir.anciente En ese momento, pero le gustaría moverlo más tarde, deberá copiar el archivo existente. antiguo carpeta manualmente y luego iniciar Geth con --datadir.anciente establecer en el camino correcto.

Trucos de congelación

Dado que el congelador (datos en frío) se almacena por separado del estado (datos en caliente), una pregunta interesante es: ¿qué sucede si una de las dos bases de datos desaparece?

• Si el congelador se elimina (o se especifica una ruta incorrecta), básicamente, tira de la alfombra debajo de Geth. El nodo se volvería inutilizable, por lo que prohíbe explícitamente hacer esto en el inicio.
• Si, sin embargo, el base de datos del estado es el que se elimina, lo hará Geth reconstruir todos sus índices basados ​​en los datos congelados; y luego hacer una sincronización rápida en la parte superior para relleno el estado faltante

Esencialmente, el congelador se puede utilizar como guerrero estado podador Periódicamente deshacerse de la basura acumulada. Al eliminar la base de datos de estado, pero no el congelador, el nodo realizará una sincronización rápida para obtener el estado más reciente, pero reutilizará todos los datos existentes de bloque y recibo ya descargados anteriormente.

Puede activar esto a través de geth quitadob (más el --datadir y --datadir.anciente banderas si usaste las personalizadas); pidiéndole que solo elimine la base de datos de estado, pero no la base de datos antigua.

Tenga en cuenta que la reindexación de todas las transacciones de la base de datos antigua puede demorar más de una hora, y la sincronización rápida solo comenzará después. Esto probablemente se convertirá en un proceso en segundo plano en un futuro próximo.

¿A quién no le encanta JSON-RPC? ¡Yo!

Como su nombre lo indica, JSON-RPC es un Procedimiento remoto Llamada protocolo. Su objetivo de diseño es permitir. funciones de llamada, que hacen algún cálculo arbitrario en el lado remoto, después de lo cual devuelven el resultado de dicho cálculo. Por supuesto, ya que el protocolo es genérico, puede ejecutar consultas de datos en la parte superior, pero no hay una consulta semántica estandarizada, por lo que las personas tienden a rodar las suyas.

Sin embargo, sin el soporte para consultas flexibles, terminamos desperdiciando recursos computacionales y de transferencia de datos:

• Llamadas RPC que devuelven una gran cantidad de datos (por ejemplo, eth_getBlock) desperdiciar ancho de banda si el usuario solo está interesado en unos pocos campos (por ejemplo, solo el encabezado, o incluso menos, solo la dirección del minero).
• Las llamadas RPC que devuelven solo un poco de datos (por ejemplo, eth_getTransactionReceipt) desperdiciará la capacidad de la CPU si el usuario se ve obligado a repetir la llamada varias veces (por ejemplo, recuperar todos los recibos uno por uno resulta en la carga) todos ellos del disco para cada llamada).

En el caso de la API JSON-RPC de Ethereum, los problemas anteriores se ven exacerbados por la naturaleza de mini-reorganización de la cadena de bloques, al hacer múltiples consultas (por ejemplo, eth_getBalance) deben asegurarse de que se ejecuten en el mismo estado e incluso en el mismo nodo (por ejemplo, los backends de carga equilibrada pueden tener ligeros retrasos de sincronización, por lo que pueden ofrecer contenido diferente).

Sí, podríamos inventar un nuevo mecanismo de consulta súper óptimo que nos permita recuperar solo los datos que necesitamos, al mismo tiempo que minimizamos la sobrecarga computacional y de transferencia de datos … o también podríamos no reinventar la rueda (de nuevo) y usar uno que haya sido ya probado: GraphQL.

Consultando con GraphQL

¡Lo primero es lo primero, un gran saludo para Nick Johnson por ser pionero tanto en la especificación GraphQL y su implementación, como en Guillaume Ballet por hacer las integraciones finales!

Geth v1.9.0 introduce capacidades de consulta GraphQL nativas a través de --gráfico Bandera de la CLI. GraphQL es un protocolo sobre HTTP, el mismo conjunto de subetiquetas (restricciones, CORS y reglas de hosts virtuales) están disponibles como para HTTP RPC. Pero basta de esta yada-yada, ¡vamos a verla!

Para un giro rápido, ¡intentemos encontrar todos los registros de dominio de ENS en Görli testnet! Inicie Geth v1.9.0 en Görli con GraphQL habilitado (geth --goerli --graphql), espere hasta que se sincronice (debe estar entre 1 y 2 minutos como máximo) y apunte su navegador al … jadeo … construido en el explorador GraphQL en http: // localhost: 8547!

Para simplificar las cosas, aquí hay una consulta de muestra rápida que encuentra el ENS HashRegistrado eventos y devuelve la dirección del usuario que realiza el registro junto con el número de bloque y la marca de tiempo en la que se incluyó:

Si bien el ejemplo es un poco ingenioso y simplista, destaca que GraphQL nos permite responder a "consultas de combinación" complejas que anteriormente requerían muchas llamadas RPC y devolvieron mucha más información de la que realmente necesitamos.

Al igual que con todas las herramientas de desarrollo épicas, el explorador GraphQL de Geth v1.9.0 ha integrado la finalización de código, la documentación de campo y la ejecución de consultas en vivo. Ve y consulta algo impresionante!

¡Geth ya admitía ciertas carteras de hardware en el pasado, pero con la versión v1.9.0, hemos mejorado nuestro juego y hecho que la lista sea mucho más extensa!

Carteras de libro mayor

Ya hemos apoyado el Ledger Nano S durante un par de años, ¡pero Geth v1.9.0 también presenta soporte nativo para el Ledger Nano X (a través de USB)!

Además, v1.9.0 reemplaza la ruta de derivación HD predeterminada de la heredada, que Ledger anunció originalmente, a la canónica, utilizada por todas las carteras Ethereum (y actualmente también por Ledger). ¡No se preocupe, Geth también encontrará todas sus cuentas antiguas, solo usará la ruta canónica para las nuevas cuentas! Este trabajo fue realizado por Péter Szilágyi.

Si no ha utilizado un Libro mayor a través de Geth hasta ahora, el flujo de trabajo es:

• Conecte su Ledger Nano S o Ledger Nano X y desbloquee a través de su código PIN.
• Inicie la aplicación Ethereum en su libro mayor (Geth registrará Aplicación Ethereum fuera de línea).
• Puedes listar todas tus cuentas a través de personal.listWallets desde la consola geth.
  • Esto derivará automáticamente todas las cuentas que hayas utilizado antes de + 1 vaciar una nueva.
  • Alternativamente, puede hacer lo mismo a través de RPC a través de personal_listWallets.
• Realice la transacción a través de sus medios preferidos y Geth enviará la solicitud de firma al Libro mayor.

Los usuarios de Linux deben tener en cuenta que debe permitir explícitamente que su usuario acceda a su cartera de libro mayor a través de udev ¡reglas!

Carteras de trezor

Durante casi dos años hemos apoyado al Trezor One. Desafortunadamente, una actualización de firmware (v1.7.0 +) cambió el protocolo USB de una manera incompatible hacia atrás. Si bien recomendamos que todos usen el software más reciente cuando se trata de seguridad, también reconocemos la renuencia de actualizar el firmware regularmente en un dispositivo de almacenamiento en frío.

Como tal, Geth v1.9.0 implementa el nuevo protocolo WebUSB compatible con los modelos actualizados de Trezor One, pero al mismo tiempo sigue siendo compatible con el antiguo protocolo HID USB para dispositivos no actualizados. Este soporte fue agregado por Guillaume Ballet y Péter Szilágyi (incluso hemos publicado una nueva USB biblioteca para ir a apoyarlo).

El flujo de trabajo de Trezor One es un poco más complejo debido a la entrada de PIN única:

• Conecte su Trezor One, Geth lo detectará pero le pedirá que lo abra.
• Llamada personal.openWallet ('trezor: // ...') con la URL del dispositivo.
  • Si no conoce la URL, puede verificarla a través de personal_listWallets.
  • La consola seguirá solicitando la entrada del PIN y la contraseña, según sea necesario.
  • Llamando a través de RPC, OpenWallet devuelve un error detallado si necesita otra llamada.
• Puede enumerar todas sus cuentas a través de personal.listWallets desde la consola Geth.
  • Esto derivará automáticamente todas las cuentas que hayas utilizado antes de + 1 vaciar una nueva.
  • Alternativamente, puede hacer lo mismo a través de RPC a través de personal_listWallets.
• Realice la transacción a través de sus medios preferidos y Geth enviará la solicitud de firma al Trezor.

Además del soporte extendido para Trezor One, Geth v1.9.0 también presenta soporte nativo para el Trezor Model T. El flujo de trabajo del Model T es un poco más sencillo ya que la entrada del PIN se realiza en el dispositivo:

• Conecte su Trezor Model T y desbloquee a través de su código PIN, Geth debería detectarlo.
• Puedes listar todas tus cuentas a través de personal.listWallets desde la consola geth.
  • Esto derivará automáticamente todas las cuentas que hayas utilizado antes de + 1 vaciar una nueva.
  • Alternativamente, puede hacer lo mismo a través de RPC a través de personal_listWallets.
• Realice la transacción a través de sus medios preferidos y Geth enviará la solicitud de firma al Trezor.

Los usuarios de Linux deben tener en cuenta que debe permitir explícitamente que su usuario acceda a su billetera Trezor a través de udev ¡reglas!

Tarjetas de estado

Prototipado hace más de un año, Geth v1.9.0 finalmente ofrece soporte para la tarjeta de estado, una billetera de hardware de alta definición basada en tarjetas inteligentes de Java. La tarjeta de estado de la tarjeta se puede usar a través de Geth solo a través del demonio PC / SC por ahora (es necesario que la instale) y por medio de USB (el + iD es un buen lector de tarjetas inteligentes USB). Este trabajo fue elevado por Nick Johnson, inicialmente integrado por Péter Szilágyi y finalizado por Guillaume Ballet (y, por supuesto, Andrea Franz y el resto del equipo de Status).

Si ya tiene una tarjeta de acceso de estado inicializada, el flujo de trabajo de Geth es:

• Conecte su tarjeta de estado a través de un lector de tarjetas USB.
• Compruebe el estado de su tarjeta a través de personal_listWallets.
• Permitir a Geth usar la tarjeta via personal.openWallet ('keycard: // ...').
  • La primera vez que Geth le pedirá que vincule su tarjeta a través de la frase de contraseña.
  • En el funcionamiento normal, Geth le pedirá que desbloquee su tarjeta a través de su código PIN.
  • Con demasiados PIN incorrectos, Geth le pedirá que reinicie su tarjeta a través de su código PUK.
  • En demasiados PUK incorrectos, su tarjeta será bloqueada y tendrá que volver a instalarla.
  • Alternativamente, puede hacer lo mismo a través de RPC a través de múltiples personal_openWallet ().
• Realice la transacción a través de sus medios preferidos y Geth enviará la solicitud de firma a la tarjeta de estado.

Si no tiene una tarjeta de estado preinicializada; están utilizando una tarjeta de desarrollador; o lograron bloquear su tarjeta existente (hey, somos desarrolladores, debe saber qué sucede entonces), puede seguir nuestra guía técnica sobre cómo limpiar su tarjeta de acceso y reinicializarla. Tenga en cuenta que perderá su clave privada en un borrado.

¡Carteras, carteras por todos lados!

Cuando se lanzó Ethereum en 2015, no había ninguna herramienta de terceros en absoluto, por lo que las implementaciones de los clientes tenían que ser estas navajas suizas que lo abarcaban todo. Desde la red de igual a igual, a través de la gestión de la cuenta, a las interacciones de contrato y usuario, todo fue hecho por el cliente. Esto fue necesario, pero muy subóptimo: las cuentas y las redes no van bien juntas en cuanto a seguridad, y todo lo que se hace mediante un solo binario no permite un ecosistema composable.

Hemos estado deseando hacer esto durante al menos 2 años, y Geth v1.9.0 finalmente envía el trabajo de Martin Holst Swende (con la ayuda de muchos otros): un firmante independiente para el todo Llamado ecosistema etéreo Clave. Tan simple como podría sonar un "firmante independiente", Clef es el resultado de una increíble cantidad de trabajo arquitectónico para que sea seguro, flexible y composable.

Una pequeña publicación de blog simplemente no puede hacer justicia a este proyecto, pero intentaremos, al menos, mencionar las principales características de Clef, las decisiones de diseño detrás de ellas y cómo pueden habilitar todo un conjunto de nuevos casos de uso.

Composabilidad del ecosistema

La razón principal para crear Clef fue eliminar la administración de la cuenta de Geth (no se preocupe, la forma antigua todavía funcionará en el futuro inmediato). Esto permite que Geth sea una pasarela de red "insegura" hacia Ethereum, que debería resolver muchos problemas relacionados con la exposición accidental de cuentas a través de RPC (y su desbloqueo, el combo mortal).

Pero acaparar todo este trabajo para Geth no sería agradable de nuestra parte. En su lugar, diseñamos Clef para que pueda ser utilizado por programas arbitrarios, de modo que pueda tener un único firmante de forma segura administrando sus claves, a las cuales las aplicaciones arbitrarias (por ejemplo, Geth, Parity, Trinity, Metamask, MyCrypto, Augur) pueden enviar solicitudes de firma a!

Para lograr esto, Clef expone una pequeña API externa (registro de cambios) a través de IPC (predeterminado) o HTTP. Cualquier programa que pueda acceder a estos puntos finales (por ejemplo, Geth a través de IPC, Metamask a través de HTTP) puede enviar solicitudes de firma a Clef, que solicitará al usuario la confirmación manual. La API es deliberadamente pequeña y utiliza JSON-RPC, por lo que debería ser trivial para ser compatible con cualquier proyecto.

Nuestro objetivo con Clef es no ser. "El firmante Geth", más bien, nos gustaría que se convirtiera en una entidad independiente que pueda ser utilizada por cualquier otro proyecto, ya sean diferentes implementaciones de clientes (Trinity), integraciones de navegador (Metamask), componentes de servicio (Raiden) o aplicaciones descentralizadas (Augur). Si desea integrar Clef, ¡comuníquese con nosotros y nosotros HEPLARÁ!

Interfaz enchufable

¿Cuál es la interfaz de usuario perfecta?

Si me preguntas, te diría línea de comando: simple, funciona sobre SSH, y puedo codificarlo: D. Pero soy una minoría aquí e incluso a menudo prefiero una UI adecuada. Asi que, Electrón? Algunos piensan que es lo mejor desde el pan rebanado y muchos desarrolladores pueden codificarlo; pero es grande y lento y JavaScript: P. Qué tal si Qt? Es multiplataforma, pequeña y rápida, pero no muchos desarrolladores están familiarizados con ella y tiene una licencia funky. Android, GTK, iThingy? … Win32?

La respuesta es todos ellos! La interfaz de usuario perfecta depende de para qué la quiere usar, y no queremos hacer esa elección por usted, sino permitirle ejecutar Clef de la forma que mejor se adapte a su vida:

• Si está en movimiento todo el tiempo, puede preferir una interfaz de Android o iOS.
• Si tiene un servidor remoto bloqueado, es posible que prefiera CLI sobre SSH.
• Si tienes una computadora portátil poderosa, la belleza de Electron podría ser la cosa.
• Si tiene una máquina de firmante fuera de línea, una interfaz de usuario Qt puede ser simple, pero suficiente.
• Si usted es un banco, es posible que desee una integración personalizada en su propia infraestructura.

No podemos implementar todo esto. ¡Pero puedes! Hemos diseñado Clef con la flexibilidad suficiente para permitir que cualquier persona pueda implementar una interfaz de usuario personalizada en la parte superior, sin necesidad de tocar Clef en sí misma, ni conocer ningún Go en absoluto. El objetivo es proporcionar un bloque de construcción a la comunidad para que los diseñadores y desarrolladores de UI puedan hacer lo que hacen bien, sin tener que preocuparse por la criptografía y esas cosas.

Para lograr esto, Clef expone una API interna extendida (registro de cambios), solamente A través de entrada / salida estándar. Cualquier interfaz de usuario está diseñada para iniciarse e iniciar internamente una instancia de Clef, enlazando a sus flujos de IO. Las secuencias de IO hablan JSON-RPC, por lo que la interfaz de usuario puede enviar de forma arbitraria de confianza las solicitudes a Clef, y Clef enviará notificaciones y avisos de confirmación a la interfaz de usuario.

Clef se envía con una interfaz CLI incorporada (de lo contrario, no es muy útil) y hemos preparado una Guía de inicio rápido completa para familiarizarse con las características y conceptos generales. También hay varias interfaces de usuario de prueba de concepto que hemos utilizado para validar las decisiones arquitectónicas, pero para obtener una interfaz de usuario sólida, necesitamos a la comunidad, ¡ya que no tenemos conocimiento de nosotros mismos!

4bytes integrados

Probablemente ya te habrás dado cuenta de la dirección general. Queremos que Clef sea una pieza de rompecabezas reutilizable. ¡El truco es hacerlo del tamaño correcto! Demasiada funcionalidad incorporada (por ejemplo, IU fija), y los posibles usos se limitan. Muy pocos (por ejemplo, sin cartera de hardware) y los constructores de interfaz de usuario reinventan la rueda. Es un delicado equilibrio entre maximizar la utilidad y la seguridad sin comprometer la flexibilidad.

Por lo tanto, estamos de acuerdo en que "UI mal arreglada, UI conectable, buena", "ninguna billetera de hardware está mal, Ledger + Trezor + Keycard buena". ¿Qué más reinventan las implementaciones de billetera todo el tiempo? 4 bytes!

En Ethereum, siempre que un usuario interactúa con un contrato, envía un blob gigante de datos binarios, codificados en un formato ABI muy específico. Esto es necesario para que el EVM pueda hacer cara o no, y por supuesto esto es generado por algún programa (por ejemplo, Augur). El problema es que se le pide al usuario que confirme una transacción que se parece a esto:

La solución de la comunidad Ethereum fue reunir una 4byte base de datos, de modo que al observar los primeros 4 bytes de los datos anteriores, puede adivinar qué representa el resto de los datos y, por lo tanto, puede mostrar al usuario un volcado significativo de lo que están a punto de confirmar (imágenes arriba y abajo). debajo cortesía de Etherscan).

Actualmente, todas las interfaces de usuario de Ethereum Wallet reinventan la rueda cuando se trata de integrar 4bytes. La base de datos es pública, pero las integraciones son personalizadas. Clef envía toda la base de datos de 4 bytes incorporada, y cada vez que se realiza una transacción, decodifica los datos de llamada internamente. Clef no solo envía la llamada descodificada a la interfaz de usuario, sino que también agrega mensajes de advertencia si los datos no coinciden con la firma del método. Clef manejará Ethereum, ¡puedes enfocarte en la interfaz de usuario!

Reglas programáticas

Clef parece increíble, ¿qué más podemos pedir? Bueno … según las secciones anteriores, podemos crear el firmante perfecto para confirmar todas y cada una de nuestras transacciones … manualmente. Sin embargo, qué sucede si queremos automatizar algo de eso (por ejemplo, firmante de clique, relé de Raiden, intercambio de Swarm, etc.). Nosotros podría no importa y deje que la UI lo resuelva … pero volvemos al punto de partida, ya que todas las UI envolventes deben reinventar los mismos mecanismos, y la mayoría probablemente lo hará de manera insegura.

¡Clef resuelve esto a través de un almacén de clave-valor cifrado y un ingenioso motor de reglas! En lugar de pedirle al usuario que confirme cada solicitud a través de una entrada de frase de contraseña, podemos permitir que Clef firme en nuestro nombre almacenando nuestra frase de contraseña en su base de datos cifrada. ¡Esto solo permitirá la firma sin contraseña, pero aún necesita confirmación manual!

Sin embargo, como segundo paso, también podemos proporcionar a Clef un archivo de reglas de JavaScript, que se ejecutará cada vez que llegue una solicitud y podremos decidir si se confirma automáticamente, se rechaza automáticamente o reenvía la solicitud de confirmación manual. Las reglas de JavaScript tienen acceso a toda la solicitud y también pueden almacenar datos arbitrarios en un almacén de valor-clave para la persistencia. P.ej. Un archivo de reglas de demostración académica:

función ApproveSignData(req) 
    Si (req.dirección.toLowerCase() == "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3") 
        Si (req.mensajes(0).valor.índice de("bazonk") > = 0) 
            regreso "Aprobar"
        
        regreso "Rechazar"
    
    // De lo contrario va al procesamiento manual.

El objetivo de estas reglas es permitirle configurar una lógica de aprobación arbitraria para lo que sea su caso de uso, ya sean transacciones automáticas del lado del servidor (Clique, Raiden, Swarm, Faucet) o automatización del lado del cliente de bajo valor (aprobar X Wei / 24h a Augur). Las reglas programables aseguran que Clef se mantenga fiel a su promesa de composición, permitiendo que cualquiera pueda construir la integración de sus sueños en la parte superior.

Para obtener una demostración completa sobre cómo configurar reglas automáticas, consulte la Guía de inicio rápido de Clef.

Los clientes ligeros son difíciles y hacen que todo sea más complicado de lo que debería ser. La causa principal es más filosófica que técnica: las mejores cosas de la vida son gratis y las segundas mejores son baratas. En términos de cliente de Ethereum, el "mejor" los clientes son aquellos que trabajan con 0 sobrecarga (piense en Metamask, Infura), los segundos mejores son los clientes livianos.

El problema es que los servidores de confianza van en contra de la ética del proyecto, pero los clientes ligeros a menudo son demasiado pesados ​​para los dispositivos con recursos limitados (Ethash asesina la batería de su teléfono). Geth v1.9.0 envía un nuevo modo para clientes livianos, llamado cliente ultra ligero. Este modo apunta a posicionarse a medio camino en el espectro de seguridad entre un servidor confiable y un servidor liviano, reemplazando la verificación de PoW con firmas digitales de la mayoría de los servidores confiables.

Con suficientes firmas de entidades independientes, podría alcanzar una seguridad más que suficiente para las aplicaciones no críticas. Dicho esto, el modo de cliente ultraligero no está realmente destinado a su nodo promedio, sino a los proyectos que desean enviar Geth embebido en su propio proceso. Este trabajo fue encabezado por Boris Petrov y Status.

Punto de control oracle

¡Los clientes ligeros son pequeños trucos sucios! En lugar de descargar y verificar cada encabezado de la génesis a la cabeza de la cadena, utilizan un punto de control codificado (enviado dentro de Geth) como punto de partida. Por supuesto, este punto de control contiene todas las informaciones necesarias para verificar criptográficamente incluso los encabezados anteriores, por lo que, por seguridad, no se pierde nada.

Aun así, tan útiles como son los puntos de control incrustados, tienen sus defectos:

• Como los puntos de control están codificados en nuestros binarios de lanzamiento, los lanzamientos más antiguos siempre comenzarán a sincronizarse desde un bloque más antiguo. Esto está bien por unos pocos meses, pero eventualmente se vuelve molesto. Por supuesto, puede actualizar Geth para obtener un nuevo punto de control, pero eso también incluye todos nuestros cambios de comportamiento, que es posible que no quiera hacer por cualquier motivo.
• Dado que estos puntos de control están incrustados en el código, no tendrá suerte si desea admitirlos en su propia red privada. Necesitará enviar un Geth modificado o configurar los puntos de control a través de un archivo de configuración, distribuyendo un nuevo uno cada vez que actualice el punto de control. Se puede hacer, pero no es realmente práctico a largo plazo.

Aquí es donde el trabajo de Gary Rong y Zsolt Felföldi entra en juego. Geth v1.9.0 incluye soporte para un punto de control en cadena. En lugar de confiar en puntos de control codificados, los clientes ligeros pueden comunicarse con no confiable Servidores de luz remotos (punto a punto, sin bs centralizados) y pídales que devuelvan un punto de control actualizado almacenado dentro de un contrato inteligente dentro de la cadena. La mejor parte, los clientes ligeros pueden demostrar criptográficamente que los datos devueltos fueron firmados por un número requerido de firmantes aprobados.

Espere, ¿cómo sabe un cliente ligero quién está autorizado para firmar un punto de control en la cadena? Para redes admitidas fuera de la caja, Geth se envía con direcciones de Oracle de punto de control codificadas y listas de firmantes autorizados (por lo que confía en los mismos desarrolladores que envían Geth). Para redes privadas, los detalles de Oracle se pueden especificar a través de un archivo de configuración.

Aunque los mecanismos de punto de control antiguos y nuevos parecen similares (ambos requieren datos codificados de forma rígida en Geth o un archivo de configuración), el nuevo oráculo de punto de control debe configurarse sólo una vez y luego se puede utilizar arbitrariamente largo para publicar nuevos puntos de control.

punto de control-admin

Los contratos de Ethereum son poderosos, pero interactuar con ellos no es para los débiles de corazón. Nuestro contrato de checkpoint oracle es una bestia especialmente desagradable, porque a) se esfuerza por conservar la seguridad incluso ante los reorgs de la cadena; y b) debe admitir compartir y probar puntos de control para clientes que aún no están sincronizados.

Como no esperamos que nadie (ni siquiera nosotros mismos) interactúe manualmente con el punto de control oracle, Geth v1.9.0 también envía una herramienta de administración específicamente para este contrato, punto de control-admin. Tenga en cuenta que solo tendrá que preocuparse por esto si desea ejecutar su propio punto de control para su propia red privada.

los punto de control-admin se puede utilizar para consultar el estado de un contrato ya implementado (--rpc debe apuntar a un nodo ligero o a un nodo completo con --lighterv habilitado, tanto con el les Espacio de nombres de la API RCP expuesto):

$ checkpoint-admin --rpc ~ / .ethereum / rinkeby / geth.ipc status
Oracle => 0xebe8eFA441B9302A0d7eaECc277c09d20D684540

Admin 1 => 0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3
Admin 2 => 0x78d1aD571A1A09D60D9BBf25894b44e4C8859595
Admin 3 => 0x286834935f4A8Cfb4FF4C77D5770C2775aE2b0E7
Admin 4 => 0xb86e2B0Ab5A4B1373e40c51A7C712c70Ba2f9f8E

Punto de control (publicado en # 4638418) 140 => 0x488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef

El comando admin también se puede utilizar para desplegar un nuevo oráculo, firmar un puesto de control actualizado y publicar En la red. Además, punto de control-admin También funciona en modo fuera de línea (sin una cadena en vivo para proporcionar datos) y también puede ser respaldado por clave para firmar en lugar de usar archivos clave, pero describir todo esto es para otro día.

Esto es quizás algo que no muchos sabían, pero desde casi siempre, Geth había incorporado soporte para monitorear diferentes subsistemas y eventos. Naturalmente, la versión original era bastante tosca (texto IU, informes RPC), pero proporcionó el trabajo de base. ¡Podemos hacerlo mejor que esto!

Colección de métricas

En primer lugar, las métricas se deben recopilar antes de poder exportarlas y visualizarlas. Geth puede recibir instrucciones para recopilar todas sus métricas conocidas a través de --métrica Bandera de la CLI. Para exponer estas mediciones al mundo exterior, Geth v1.9.0 presenta 3 mecanismos independientes: ExpVars, InfluxDB y Prometheus.

ExpVars es un medio un tanto personalizado en el ecosistema de Go para exponer las variables públicas en una interfaz HTTP. Geth usa su debug pprof punto final para exponer estos en. Ejecutando Geth con --metrics --pprof expondrá las métricas en expvar formato en http://127.0.0.1:6060/debug/metrics. Tenga en cuenta que nunca debe exponer el pprof Punto final de HTTP a la Internet pública, ya que puede utilizarse para desencadenar operaciones que requieren un uso intensivo de recursos

ExpVars está bien soportado dentro del ecosistema Go, pero no es el estándar de la industria. Un mecanismo similar, pero con un formato más estandarizado, es el punto final de Prometheus. Ejecutando Geth con --metrics --pprof También expondrá este formato en http://127.0.0.1:6060/debug/metrics/prometheus. Una vez más, por favor, nunca exponga la pprof Punto final HTTP a la internet pública! Grita a Maxim Krasilnikov por contribuir con esta característica.

Mientras que ExpVars y Prometheus son Halar mecanismos de monitoreo basados ​​(los servidores remotos extraen los datos de Geth), también apoyamos empujar supervisión basada a través de InfluxDB (Geth envía los datos a servidores remotos). Esta función requiere que se establezcan una serie de indicadores CLI para configurar la conexión de la base de datos (servidor, base de datos, nombre de usuario, contraseña y etiqueta de instancia Geth). Por favor vea el MÉTRICAS Y OPCIONES DE ESTADÍSTICAS Sección de geth ayuda para detalles (--metrics.influxdb y subflags). Este trabajo fue realizado por Anton Evangelatov.

Visualización de métricas

Visualizar las métricas puede ser un poco desalentador, ya que necesita elegir un programa / servicio de creación de gráficos y poner mucho trabajo en él para configurar todos los hosts, gráficos y paneles.

Nosotros mismos estamos usando Datadog internamente y hemos estado modificando contiguamente nuestros paneles de monitoreo desde que los creamos hace 1.5 años. Si ya está utilizando Datadog o está considerando hacerlo, aquí tiene un resumen de lo que puede ensamblar en función de las métricas expuestas por Geth (este es el panel a través del cual comparamos los PR con el maestro):

Desafortunadamente, Datadog no admite el uso compartido de cuadros de mandos con entidades externas (ya que dependen de cómo se configuraron las máquinas monitoreadas). Como tal, no podemos compartir fácilmente el trabajo anterior con usted, pero exportamos un volcado JSON en caso de que alguien esté dispuesto a seguir nuestros pasos.

Of course, we also understand that a paid service such as Datadog is not always ideal, especially if you are just starting out and don’t have money to burn on monitoring. A brilliant free monitoring tool is Grafana!

Maxim Krasilnikov made a Grafana dashboard a while ago against an older development version of Geth. We took his awesome work and merged into it the stats that we ourselves grew fond of in Datadog, resulting in quite a bit of extra work on Geth. The end result, however, is stunning (expect further updates over the next releases):

You can quickly reproduce the above charts via my clone of Maxim Krasilnikov’s project by running docker-compose up in the repo root and accessing http://localhost:3000 con el admin/admin credentials. Alternatively, you can view my testing snapshot on Raintank, or import this dashboard into your own Grafana instance

A long time ago in a far away land, Puppeth saw the first light of day (specifically, in Mexico, just shy of two years ago). If you haven’t head about it, “Puppeth is a tool to aid you in creating a new Ethereum network down to the genesis block, bootnodes, signers, ethstats, faucet, wallet, explorer and dashboard”. Originally it was created to support deploying and maintaining the Rinkeby testnet, but has since been used by various groups for other private networks too.

Puppeth is not a tool for maintaining a high value production network, but it has, nonetheless, proven itself robust enough to keep Rinkeby relevant for over two years now! If you’d like a deeper dive into Puppeth, here’s my reveal talk from way back. In this post however lets focus on what’s new!

Puppeth is awesome! It allowed you since day 1 to deploy a full, operational Ethereum network across multiple machines, extended with a stats page to aid maintenance, along with a faucet and a dashboard to help onboard users easily. Puppeth, however, lacked a robust block explorer, since the only contenders back then were Etherscan and Etherchain, both closed source. We did hack something in, but it was kind of meh…

With the announcement of Blockscout late last year, everything changed! The Ethereum community finally got a real, open source block explorer, courtesy of the POA Network team. Compared to the established players, Blockscout of course has some catching up to do, but that does not stop us from realizing that it is already an insanely valuable asset. As such, Geth v1.9.0 ships a preliminary integration of Blockscout into Puppeth, filling a huge hole in our private network deployment tool!

This effort was pioneered by Gary Rong, but a huge shoutout goes to Ayrat Badykov too for his help in sorting out issues, questions and whatnot.

Please note, that we expect the initial integration to be rough (e.g. due to a “bug” in Blockscout, the Puppeth explorer will need to fully sync a Geth archive node before it can boot up the explorer web interface). By all means test it, run it, report any issues, but don’t be surprised if it goes down at 3AM!

Now here’s another piece of legacy infrastructure! Apart from a teeny-tiny modification, Ethereum’s discovery protocol has been specced, implemented and set in stone since pretty much forever. For those wondering what the discovery protocol is all about, it’s the mechanism through which a new node can find other Ethereum nodes on the internet and join them into a global peer-to-peer network.

So… what’s wrong with it then? Didn’t it work well enough until now? If it ain’t broken, don’t fix it and all that?

Well, Ethereum’s original discovery protocol was made for a different time, a time when there was only one chain, when there weren’t private networks, when all nodes in the network were archive nodes. We outgrew these simplistic assumptions, which although is a success story, it also brings new challenges:

• The Ethereum ecosystem nowadays has many public, private and test networks. Although Ethereum mainnet consists of a large number of machines, other networks are generally a lot smaller (e.g. Görli testnet). The discovery protocol doesn’t differentiate between these networks, so connecting to a smaller one is a never ending trial and error of finding unknown peers, connecting to them, then realizing they are on a different network.
• The same original Ethereum network can end up partitioning itself into multiple disjoint pieces, where participants might want to join one piece or the other. Ethereum Classic is one of the main examples here, but a similar issue arises every time a network upgrade (hard fork) passes and some nodes upgrade late. Without information concerning the rules of the network, we again fall back to trial and error connectivity, which is computationally extremely expensive.
• Even if all nodes belong to the same network and all nodes adhere to the same fork rules, there still exists a possibility that peering is hard: if there is connectivity asymmetry, where some nodes depend on services offered by a limited subset of machines (i.e. light clients vs. light servers).

Long term we’re working towards a brand new version of the discovery protocol. Geth’s light clients have been since forever using a PoC version of this, but rolling out such a major change for the entire Ethereum network requires a lot of time and a lot of care. This effort it being piloted primarily by Felix Lange and Frank Szendzielarz in collaboration with Andrei Maiboroda from Aleth/C++, Antoine Toulme with Java, Age Manning from Lighthouse/Rust and Tomasz Stańczak from Nethermind/C#.

Ethereum Node Records

The above was a whole lot of text about something we didn’t ship! What we did ship however, is the Ethereum Node Record (ENR) extension of the new discovery protocol, which can actually run on top of the old protocol too! An ENR is a tiny, 300 byte, arbitrary key-value data set, that nodes can advertise and query via discovery. Although the new discovery protocol will provide fancy ways of sharing these in the network, the old protocol too is capable of directly querying them.

The immediate benefit is that nodes can advertise a lot of metadata about themselves without an expensive TCP + crypto handshake, thus allowing potential peers to filter out unwanted connections without ever making them in the first place! All credits go to Felix Lange for his unwavering efforts on this front!

Ok, ok, we get it, it’s fancy. But what is it actually, you know, useful for, in human-speak?

Geth v1.9.0 ships two extensions to the discovery protocol via ENRs:

• The current discovery protocol is only capable of handling one type of IP address (IPv4 or IPv6). Since most of the internet still operates on IPv4, that’s what peers advertise and share with each other. Even though IPv6 is workable, in practice you no poder find such peers. Felix Lange’s work on advertising ambos IPv4 and IPv6 addresses via ENRs allows peers to discover and maintain Kademlia routing tables for both IP types. There’s still integration work to be done, but we’re hoping to elevate IPv6 to a first class citizen of Ethereum.
• Finding a Rinkeby node nowadays works analogously to connecting to random websites and checking if they are Google or not. The discovery protocol maintains a soup of internet addresses that speak the Ethereum protocol, but otherwise has no idea which chain or which forks they are on. The only way to figure out, is to connect and see, which is a very expensive shooting-in-the-dark. Péter Szilágyi proposed an extension to ENR which permits nodes to advertise their chain configuration via the discovery protocol, resulting in a 0-RTT mechanism for rejecting surely bad peers.

The most amazing thing however with ENR – and its already implemented extras – is that anyone can write a UDP crawler to index Ethereum nodes, without having to connect to them (most nodes won’t have free slots; and crawlers that do connect via TCP waste costly resources). Having simple access to all the nodes, their IPs/ports, capabilities and chain configurations permits the creation of a brand new discovery protocol based on DNS, allowing nodes with blocked UPD ports (e.g. via Tor) to join the network too!

We’ve had a varying number of bootnodes of varying quality, managed by varying people since the Frontier launch. Although it worked well-ish, from a devops perspective it left a lot to desire, especially when it came to monitoring and maintenance. To go along our Geth v1.9.0 release, we’ve decided to launch a new set of bootnodes that is managed via Terraform and Ansible; and monitored via Datadog and Papertrail. We’ve also enabled them to serve light clients, hopefully bumping the reliability of the light protocol along the way. Huge shoutout to Rafael Matias for his work on this!

Our new list of bootnodes is:

• enode://d860a01f9722d78051619d1e2351aba3f43f943f6f00718d1b9baa4101932a1f5(email protected)18.138.108.67:30303 (Singapore, AWS)
• enode://22a8232c3abc76a16ae9d6c3b164f98775fe226f0917b0ca871128a74a8e9630b(email protected)3.209.45.79:30303 (Virginia, AWS)
• enode://ca6de62fce278f96aea6ec5a2daadb877e51651247cb96ee310a318def462913b(email protected)34.255.23.113:30303 (Ireland, AWS)
• enode://279944d8dcd428dffaa7436f25ca0ca43ae19e7bcf94a8fb7d1641651f92d121e(email protected)35.158.244.151:30303 (Frankfurt, AWS)
• enode://8499da03c47d637b20eee24eec3c356c9a2e6148d6fe25ca195c7949ab8ec2c03(email protected)52.187.207.27:30303 Australia, Azure)
• enode://103858bdb88756c71f15e9b5e09b56dc1be52f0a5021d46301dbbfb7e130029cc(email protected)191.234.162.198:30303 (Brazil, Azure)
• enode://715171f50508aba88aecd1250af392a45a330af91d7b90701c436b618c86aaa15(email protected)52.231.165.108:30303 (South Korea, Azure)
• enode://5d6d7cd20d6da4bb83a1d28cadb5d409b64edf314c0335df658c1a54e32c7c4a7(email protected)104.42.217.25:30303 (West US, Azure)

Our legacy bootnodes will continue to function for the time being, but will be gradually sunset in the following months.

Beside all the awesome features enumerated above, there are a few other notable changes that are not large enough to warrant their own section, but nonetheless important enough to explicitly mention.

RPC APIs:

• The origin check on WebSocket connections (--wsorigins) is enforced only when the Origen header is present. This makes it easier to connect to Geth from non-browser environments such as Node.js, while preventing use of the RPC endpoint from arbitrary websites.
• You can set the maximum gas for eth_call utilizando la --rpc.gascap command line option. This is useful if exposing the JSON-RPC endpoint to the Internet.
• All RPC method invocations are now logged at depurar level. Failing methods log as advertencia so you can always see when something isn’t right.
• Geth v1.9.0 supports the eth_chainId RPC method defined in EIP 695.

Networking:

• The default peer count is now 50 instead of 25. This change improves sync performance.
• A new CLI tool (cmd/devp2p) was added to the source tree for for debugging P2P networking issues. While we don’t distribute this tool in the alltools archive yet, it’s already very useful to check issues with peer discovery.
• The P2P server now rejects connections from IPs that attempt to connect too frequently.

Miscellaneous:

• A lot of work has gone into improving the abigen tool. Go bindings now support Solidity struct and function pointer arguments. The Java generator is improved as well. The mobile framework can create deploy transactions.
• Significant parts of the go-ethereum repo now build without CGO. Big thanks to Jeremy Schlatter for this work.

Although Go Ethereum v1.9.0 brings an impressive number of improvements, there are a few backwards incompatible changes too. This section is a rundown of all the things that got changed or sunset in the release:

• Account unlocking with open HTTP, WebSocket or GraphQL ports have been disallowed due to security reasons. Power users can restore the old behavior with the --allow-insecure-unlock CLI flag at their own risk.
• The old Ubuntu docker images and the old (monolithic) Alpine docker images have been removed as deprecated over a year ago. Unless you configured your cluster in 2016, you most probably used the slim Alpine images and are safe.
• The original geth monitor CLI command was removed along with its supporting debug_metrics RPC API endpoint. Anyone relying on monitoring should use the ExpVar, InfuxDB or Prometheus metrics reporting along with Datadog or Grafana.
• los geth bug CLI command has been removed, being an unnecessary nicety. If you encounter a bug, you can simply open an issue on our GitHub tracker and fill out the template manually.
• los les/1 y eth/62 protocols were removed. les/1 was only supported by Geth and everyone on Constantinople runs les/2 ya. eth/62 was deprecated even before Frontier, but was left in for cpp-ethereum.
• Google+ authentication has been removed from the Puppeth faucet since Google sunset its social network in the beginning of April, 2019.
• The Ledger HD wallet derivation path was updated from the orignal legacy path to the canonical ecosystem one. Accounts from old paths will still be discovered.
• The default cache allowance is chosen dynamically based on the network and sync modes. Mainnet full nodes default to 4GB, testnet and private networks to 1GB. Light clients default to 128MB. Explicit --cache is of course honored.
• The PoW calculation in Whisper v6 was incompatible with Parity due to not fully adhering to the spec. This was fixed, but it also means that Whisped v6 shipped with Geth v1.9.0 is incompatible with previous versions.
• los --lightserv y --lightpeers flags were renamed to --light.serve y --light.maxpeers respectively. The old versions are deprecated, but will continue to work for the next year or so.
• The default datadir on Windows is now derived from the LocalAppData environment variable. The old location in $HOME/AppData/Roaming is still recognized. The location change works better with Cygwin and setups using remote user accounts.
• The JSON-RPC server has been rewritten and now supports bi-directional communication. You can expose method handlers on the client side using the rpc.Client.RegisterName method. While we did test this extensively, there may be compatibility issues with the new server. Please report any RPC issues you find.

We’re really proud of this release! It took a lot longer than expected, but we wanted to ship all the breaking changes in one go to minimize potential surprises (upgrade issues); and to finalize the APIs of new features, to avoid breaking them later. Hope you too will find a gem for yourself among our shipped ~370 changes.

As with all our previous releases, you can find the:

And as a last word before signing off (better twice than none):

Warning: We’ve tried our best to squash all the bugs, but as with all major releases, we advise everyone to take extra care when upgrading. The v1.9.0 release contains database schema changes, meaning it’s not possible to downgrade once updated. We also recommend a fresh fast sync as it can drastically reduce the database size.