Stratum V2
Fecha: October 11, 2022
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
Tags: Bitcoin core, Stratum v2
Introducción
Hubo un anuncio esta mañana que anunciaba que el proyecto de código abierto que implementa Stratum v2 ya está listo para ser probado. Spiral ha estado contribuyendo a este proyecto durante algunos años. También hay algunas otras empresas que lo financian. Finalmente está listo para las pruebas.
Historia
Hace unos 4 años o así, Matt propuso BetterHash que se centraba en permitir a los mineros ser capaces de hacer su propia selección de transacciones. Hubo un esfuerzo independiente de Braaains que llamaron stratum v2 que agregó cifrado y autenticación entre mineros y pools y otras mejoras sobre stratum v1 como cambiar de JSON a binario y algunas otras optimizaciones que fueron necesarias en los últimos 10 años. Esos tres se reunieron en septiembre de 2019 para fusionar esos esfuerzos, y lo fusionaron con éxito hace tres años. Así que BetterHash ya no existe, pero las partes que queríamos están en Stratum v2, y ahora Stratum v2 es la principal propuesta que existe. Algunas personas están trabajando en braidpool y otros proyectos, pero al menos para la minería de pool como existe hoy en día, getblocktemplate estaba fuera desde 2012. Pero el estado actual de la minería de la piscina … braidpool es como una cosa tipo p2pool, ¿verdad? Que yo sepa, está todo consolidado en una propuesta y estándar.
Así que hace tres años hubo una colaboración y una especificación de protocolo, pero la única implementación en los últimos años ha sido el firmware de Braaiin para máquinas bitmain para stratum v2 y Braaiiins tiene un pool que implementa stratum v2. Durante los últimos 2 años, ha habido un esfuerzo de código abierto para construir una implementación desde cero y eso es lo que ahora está listo para ser probado. Hay muchos componentes en stratum v2.
Hay un firmware que se ejecuta en las máquinas de minería, hay un software de pool y servicios que pueden ejecutarse en el lado de la minería, como un proxy de traducción que permite a las máquinas con firmware stratum v1 conectarse a un pool stratum v2. Así que la implementación de código abierto (SRII stratum v2 reference implementation). SRI implementa job negotiator proxy, que es el subprotocolo que permite a los mineros hacer la selección de transacciones. También hay trabajo de Bitcoin Core en un nuevo productor de plantillas que habla SP2. Coverdale hizo ese trabajo.
El plan había sido previamente escribirlo en rust y eso habría sido una introducción de rust en el proyecto Bitcoin Core. Hace aproximadamente un mes, hablamos y acordamos escribirlo en C++ para eliminar esa fricción. Chris dijo que estaba más cómodo en rust de todos modos, así que probablemente abrirá un PR en una semana o dos en el Core repo en una semana o dos.
Hace tres años, creo que la adopción de Stratum v2 era más un interrogante que la implementación. ¿Lo adoptarían los pools? ¿La adoptarían los mineros? Estamos viendo una fuerte respuesta a la adopción por parte de pools, mineros y fabricantes de mineros. Se ha manifestado interés. Espero que uno de ellos anuncie pronto su implantación, y otro también. En cuanto a los pools, Foundry es el más grande y está financiando la implantación, y creo que la adopción parece bastante prometedora. En este momento tenemos que asegurarnos de que el software funciona realmente y corregir los errores. Creo que empezaremos a ver hashrate real en stratum v2 el año que viene.
Stratum v2 para Bitcoin Core
A un alto nivel, el modelo que Bitcoin Core necesita considerar para Stratum v2 es que tienes el pool de minería, tienes algún proxy que es una raspberry pi en la granja o quizás algo mejor. Pero básicamente una Raspberry Pi en la granja, y luego un montón de ASICs todos hablando con el mismo proxy en tu granja.
El proxy está ejecutando el cliente SRI. Hay un software que habla con el grupo y los ASICs. Y también en el mismo dispositivo se está ejecutando Bitcoin Core. El software del proxy que otras personas están manejando es responsable de sacar las plantillas de Bitcoin Core. Ahora usan getblocktemplate pero queremos reemplazar eso con otras cosas mágicas en Stratum v2, y entonces el proxy es responsable de construir una plantilla de bloque, comunicando detalles relevantes de la plantilla al pool y hablando con los ASICs.
Así que Bitcoin Core está siendo interrogado por un proxy y todo eso es materia en esta sala, correcto. Hay otro modelo de despliegue que también debería ser considerado, que es quitar Bitcoin Core de la granja y moverlo a otro lugar. Es útil considerar un modelo en el que tanto el pool como la granja, por la razón que sea, probablemente no quieran ser responsables de la selección de la plantilla de bloques y quieran exportar ese rol enteramente a algún tercero, básicamente cualquiera que ejecute un nodo bitcoin con una bandera de opción activada.
Esto significa que este canal de comunicación está autenticado. Estamos cambiando las primitivas criptográficas para que usemos las que Bitcoin Core ya soporta como secp y AES y quizás ChaCha básicamente código que ya está en Bitcoin Core. Chris Coverdale está trabajando en una implementación de este protocolo específico para Bitcoin Core.
getblocktemplate es ineficiente. Pasa por múltiples codificaciones. Queremos dar la vuelta al modelo de cómo el trabajo sale de Bitcoin Core. Esta es la parte interesante. Actualmente para obtener datos de trabajo de Bitcoin Core, el pool hoy y en el futuro este proxy stratum v2 llamará a getblocktemplate cuando decida que quiere un nuevo bloque. Hay un montón de lógica en los servidores de pool que queremos que viva en Core. Ahora mismo los servidores de pool se conectan a Bitcoin Core por p2p o zeromq y reciben notificaciones de nuevos bloques encontrados, y también se conectan por getblocktemplate que soporta longpolling pero nadie lo usa porque en realidad nadie usa esa característica. Realmente queremos darle la vuelta a esto. ¿Por qué decide el servidor del pool? No tiene mucha información, así que normalmente la lógica es bastante tonta. Cuando te enteras de que un bloque ha llegado en p2p, como el mensaje de bloque compacto o un mensaje de cabecera, o cada segundo o cada minuto o algún tonto trozo de tiempo. Eso es tonto porque el servidor del pool no tiene ningún conocimiento relevante pero Bitcoin Core tiene un buen conocimiento sobre cuando cambiar a un nuevo bloque. Si entra una gran transacción con una gran comisión, deberías cambiar a esa plantilla porque quieres esa comisión. Si no ha entrado nada relevante durante un tiempo, quizás no te importe. Si entra un nuevo bloque que acaba de ser validado, entonces probablemente deberías estar minando encima de alguna plantilla preconsiderada que no haya pasado por la lógica completa de createnewblock. Se puede predecir cómo será el siguiente bloque, así que se puede pasar por el hit y eliminar transacciones conflictivas e ir al siguiente bloque mucho más rápido de lo que se puede hacer hoy porque hay que llamar a createnewblock, que hoy es lento.
Si trasladamos la lógica del proxy o del pool a Bitcoin Core, puede ser un protocolo push en lugar de un protocolo de sondeo. Así que uno de los objetivos clave aquí es que el protocolo esté basado en push. El protocolo sólo se conecta y recibe una notificación que dice aquí hay nuevo trabajo aquí están las transacciones o lo que sea y luego lo utiliza. Puedes conectarte, de hecho lo hace, no sé si Bitcoin Core lo hará alguna vez, pero te dice cómo de grandes tienen que ser los datos de las transacciones de Coinbase. Los pools implementan mal getblocktemplate y dicen que Bitcoin Core siempre guarda 1k para el bloque que nunca se usa, como si siempre fuera 990k o algo así. Creo que hay una manera de decirle a getblocktemplate pero los pools siguen sin hacerlo y luego se quejan de que sus bloques no son válidos. Creo que hay un buffer de 1k, y podríamos deshacernos de eso, tal vez tenga sentido o tal vez no valga la pena. Es un nuevo protocolo, así que es exacto; el proxy es el que construye el bloque. Así que la cosa que se comunica con Bitcoin Core sabe exactamente el tamaño.
Una vez que tenemos este protocolo, el trabajo está en Bitcoin Core para hacer todas estas otras mejores ideas de cómo hacer bloques. Eso es obviamente una buena cantidad de trabajo. La capacidad de cambiar bloques muy rápidamente es valiosa. La capacidad de decidir más activamente cuándo cambiar a un nuevo bloque basándose en las transacciones que llegan al mempool o cosas así. Podría ser un buen juego de rentabilidad para los mineros, pero alguien tendría que implementarlo.
El primer paso es poner en marcha el protocolo. Con suerte ccdle12 abrirá un pull request en la próxima semana o así. Una vez que tengamos eso en su lugar, podemos empezar a optimizar la forma en que los bloques son empujados a ella en lugar de sólo no sé lo que su parche actual hace en realidad.
Ésos son probablemente todos los detalles relevantes para este público, al menos en lo que se refiere a futuras direcciones y a por qué estar entusiasmados.
P: ¿Cuál es el estado actual del trabajo de Core? Alguien abrió un PR con un componente de óxido.
R: Hablamos con Chris y lo lanzamos básicamente. El código proxy que existe en la actualidad (la implementación de referencia de estrato SRI) está escrito en rust, tiene un proxy y un pool y expone una interfaz FFI que se puede llamar en C y que puede realizar la desenmarcación, deserialización y lectura de mensajes. Esa era la única parte que iba a ser incluida en Core, y entonces el código C++ llamaría a la magia de la deserialización de mensajes, pero en realidad son sólo cuatro mensajes y por eso Chris simplemente lo reescribió en C++, ya que no valía la pena luchar esa batalla. Tiene intención de abrir el pull request la semana que viene.
P: ¿Todas las mejoras para getblocktemplate?
R: No, nadie ha trabajado en eso. getblocktemplate tiene un sondeo largo, pero nadie lo usa, así que no hay razón para optimizar cuando las cosas de sondeo largo deciden enviar un bloque porque literalmente nadie lo usa. Hoy no hay grupos existentes. No hay pools importantes. Hay código para usarlo, pero ningún pool importante lo usa.
P: ¿Por qué no llamar en un bucle continuamente?
R: Estarías manteniendo csmain para siempre. Así que competirías con la aceptación de nuevos bloques. Resulta que Bitcoin Core sigue siendo single threaded.
Si hubiera un protocolo push que todo el mundo usara, entonces tendría sentido hacer ese trabajo. Creemos que con SRI, la gente realmente usaría un protocolo basado en push, y entonces tendría sentido hacer todas estas optimizaciones.
P: Has mencionado una situación en la que, si llega una transacción jugosa, es posible que quieras cambiar tu plantilla de bloques. En ese caso, ¿se renuncia a mucho trabajo?
R: No. El cambio tiene un coste a nivel de hardware. Por lo general, hay que purgar… los chips están diseñados para seguir funcionando y hay que purgarlos. Se desperdicia el trabajo de una tubería, pero eso es como, lo que, 100 nanosegundos de trabajo. No es mucho.
P: ¿Es que no hay costes irrecuperables porque la cosa de Poisson no tiene memoria?
R: No tiene memoria. Si encontrara un bloque hace 10 microsegundos, seguiría procesándolo, sólo que no incluiría esa nueva transacción que acaba de encontrar. Espero que el nuevo Stratum v2 acepte un bloque que era la plantilla anterior, supongo que sí.
Normalmente puedes cambiar lo que estás.. sin hacer flushing. Sí, hay una bandera para enjuagar o no.
Es hora de animarse a hacer bloques más inteligentes. Bloques más inteligentes, minería más inteligente. Hay mucho potencial para exprimir más ingresos de esto.
P: ¿Qué ha oído sobre la función de stratum v2 que permite a los participantes elegir una plantilla?
R: Nadie lo ha implementado todavía. Una de las principales razones por las que la gente se ha entusiasmado es que algunas de las peñas han visto el asunto del Tornado Cash. De repente, los fondos de EE.UU. no quieren responsabilizarse de la selección de las transacciones. De repente hay un interés en las preocupaciones regulatorias. Hay un fuerte deseo de hacer la selección de plantillas de mineros individuales.
Otra razón que he escuchado de los pools, escuchando de sus clientes mineros que como por razones de auditoría quieren la seguridad de stratum v2 como el cifrado y la autenticación. Sus auditores están pidiendo esto. También podría haber razones financieras y comerciales. Hay casos en los que la gente ha perdido dinero porque la gente MiTM atacó sus conexiones stratum. La mayoría de los principales mineros saben que esto podría estar ocurriendo y son completamente incapaces de detectarlo estadísticamente. Una granja pequeña no se va a dar cuenta de que le roban el 0,1% o algo así.
La cita que di en un artículo, que era sólo mi opinión, el éxito sería el 10% del hashrate a finales del próximo año sería un gran primer hito. Creo que pasarán varios años antes de que se alcance la mayoría. No todo el mundo va a tener mineros haciendo la selección de transacciones.
Una razón importante por la que el proxy que la gente va a estar ejecutando es esta cosa SRI de código abierto es que tiene el código horneado en hacer su propia transacción selectoin. Lo que realmente nos gustaría hacer y ver cómo se desarrolla, pero esto debería ser un aparato que alguien vende. Usted compra una frambuesa pi o algo un poco mejor, y viene pre-cargado con Bitcoin Core y todas estas otras cosas y hace la selección de transacciones. Otra configuración interesante es como Compass Mining y River y algunos de estos negocios de «minería alojada» donde como cliente minorista puedes comprar una máquina en la nube pero no controlas esa máquina. Si ese tipo de despliegue adopta Stratum V2, entonces como cliente minorista puedo ejecutar un nodo Bitcoin Core y hacer la selección de transacciones para mi hashrate en la nube. Te dan una forma de entrar por ssh y todo eso. Ahora Compass no tiene que hacer ninguna selección de transacciones. Podrían estar motivados por razones de cumplimiento de la OFAC para no estar involucrados en eso. O tal vez pruebas de conocimiento-cero del algoritmo estándar de selección de transacciones fue seguido, o alguna otra prueba de que podría ser interesante para los mineros.
¿Hay un desglose de las mejoras en las comisiones? Bueno, ahora mismo, las comisiones son bajas. Pero creo que la capacidad de adivinar el siguiente bloque y poder cambiar. getblocktemplate, hace años que no lo evalúo, pero no es rápido. Es como 50-100 ms. En esos 100 ms podrias haber estado minando en un bloque 90% mejor, claro que no es un bloque completamente nuevo pero el 90% es bueno y podrias haber estado minando eso todo el tiempo. A la gente le gusta mucho el argumento de «no hay bloques vacíos». Puede que no haya suficientes tasas como para que les importe, pero les gusta de todos modos.
Minería espía… esa es la otra razón para querer optimizar la parte de Bitcoin Core. Esto rompe la minería espía. El proxy de código abierto que la gente está implementando con suerte no implementará la minería espía, porque eso es un desastre. Bitcoin Core necesita ser optimizado para esto. Esta es otra discusión. Debería haber cubierto esto en realidad. Una parte importante para que la ISR sea competitiva con los pools centralizados es que el nodo necesita conseguir bloques realmente rápido. Probablemente estos nodos necesitan hacer algo más que simplemente sentarse en la red p2p como normal, probablemente necesita estar haciendo algo más inteligente como la red FIBRE necesita ser revivida de nuevo, además de la red p2p. Como ya no va a haber minería espía, la capacidad de este nodo para generar trabajo muy rápidamente cuando consigue un bloque es aún más importante. Así que tiene que estar muy bien optimizado. La minería espía sólo tiene sentido cuando la subvención es alta porque tienes que minar un bloque vacío y estás haciendo minería espía, así que si la subvención no es alta en relación con las tasas, la minería espía es inútil. Con el tiempo, importa menos. …. Así que probablemente apreciaría mucho si alguien fuera y reviviera ese viejo pull request para descargar múltiples bloques compactos en vuelo. En realidad era un viejo pull request de morcos. Alguien debería revivir y fusionar ese pull request porque haría más fácil revivir la red FIBRE que necesita existir de nuevo para hacer que esta arquitectura tenga sentido. Rebase el PR de morcos. O tal vez hagamos que morcos lo haga.