Prioridades
Fecha: March 7, 2018
Transcripción De: Bryan Bishop
Traducción Por: Blue Moon
Categoría: Core dev tech
https://twitter.com/kanzure/status/972863994489901056
Prioridades
Vamos a esperar hasta que BlueMatt esté aquí. Nadie sabe cuáles son sus prioridades. Dice que podría llegar alrededor del mediodía.
Hay un ex-director de producto de Google interesado en ayudar con Bitcoin Core. Me preguntó cómo participar. Le dije que se involucrara simplemente sumergiéndose. Pasará algún tiempo en Chaincode a finales de marzo. Nos haremos una idea de cuáles son sus habilidades. Creo que podría ser útil para gestionar cosas. Sería útil que escribiera las notas de las reuniones, o que encontrara a alguien que las escribiera, que se asegurara de que se llevan a cabo, cosas de organización. Hacer un seguimiento de las prioridades y ver dónde trabajan juntos y decir “deberíais trabajar juntos”.
Un redactor técnico es muy diferente de un gestor. Este tipo probablemente sería más del tipo de encontrar un escritor técnico, que de hacer la escritura él mismo.
Hay 600 issues abiertos, 200 pull requests. Alguien que haga un seguimiento de esto sería útil. Mantener un registro de lo que está listo para fusionar sería muy útil. No estamos haciendo un buen seguimiento de los pull requests. Podríamos hacer que alguien se dirija a la persona que abrió la incidencia y le pregunte: ¿aún crees que esto debe seguir abierto? Si era rc3 hace algunas versiones, con alguna versión extraña de qt, ese tipo de cosas, después de una cierta cantidad de tiempo, sólo hay que cerrarlas, y dejar 100-200 temas actuales abiertos. Esto requiere un cierto conocimiento técnico, sin embargo, porque tienen que ser conscientes de los problemas técnicos y cómo pull requests están ayudando a esas cuestiones.
¿Cuántas cosas se van a volver a basar al fusionar algo? Así que necesitamos un poco de ayuda con el orden de pull requests. Simplemente añadiendo algún tipo de herramienta que muestre los conflictos y lo que va a necesitar rebase - aquí hay 10 PRs listos para fusionar, si hacemos este fusionado primero, quién más va a ser impactado. ¿Qué está listo? Mejores herramientas sobre qué pull requests están listos. Tener algunas etiquetas para indicar que sería una idea útil. Github tiene una buena API y se podrían hacer consultas REST para saber qué PRs tienen qué etiquetas. Estas etiquetas podrían ayudar a los recién llegados a saber que algunos PRs están simplemente sentados y necesitan una pequeña cantidad de trabajo. A veces tienes un nuevo colaborador - en un ejemplo, un nuevo colaborador se estaba metiendo con un archivo grande, y es mucho para decirle a un nuevo colaborador que se ocupe de ello, por lo que estuvo ahí durante bastante tiempo. Los nuevos colaboradores ni siquiera saben mirar la documentación. A menudo hay que pedir a la gente que aplaste sus commits.
Qué tal tener gente con responsabilidad donde alguien en el primer día o dos de un PR, alguien tiene que decir concepto ACK o que esto necesita concepto ACK o algo así. No tiene que ser tan fuerte como un ACK, sólo que algo no es completamente odiado. Digamos que alguien quiere añadir algún RPC o cambiar alguno existente… algunas categorías de esto son totalmente benignas y a la gente no le importa, y otras veces hay consideraciones de diseño que la gente rechaza. Pero a veces es necesario motivar la prioridad porque hay otras cosas. O puedes simplemente enlazar a la gente a un FAQ que explique por qué no quieres hacer estas cosas. Tampoco hay que hacer que la barrera de entrada sea demasiado alta.
Solíamos tener etiquetas de prioridad, pero el problema era que nadie las gestionaba. Así que había asuntos de “alta prioridad” de hace 5 o 6 años que seguían teniendo prioridad. Así que no era útil. Todas las semanas preguntamos en IRC cuáles son de alta prioridad, y ni siquiera esos reciben la atención que necesitan. No estoy seguro de cuánto ayudaría volver a las etiquetas. Son muchas capas de trabajo para el proyecto. Además, la gente podría no sentirse responsable de “oh, debo una reseña o un comentario sobre si esto es una buena idea o no”. Yo también soy muy culpable de esto. Etiquetar los temas con prioridad podría no ayudar. … Pero quizá regañar sí funcione. ((risas))
Alguien debería escribir un bot que escriba en cada pull request preguntando “¿sigue siendo esto una cosa?” y luego en algún momento cerrarlo. “¿Te sientes estresado? ¿Qué tal ahora?”. o “Valora tu satisfacción sobre este pull request”.
Para ciertas partes del código, el bot debe saber a quién notificar o mencionar. Podríamos utilizar un archivo de mantenedores con las rutas de los archivos y quiénes son los mantenedores de esos archivos.No es un archivo de mantenedores, es un NAGFILE. Github sugerirá automáticamente los revisores sobre la base de un archivo.
Digamos que tienes un grupo de personas que prestan atención a una cosa.. si la gente lo ACK de ese grupo, ¿va a ser fusionado, o nadie más lo revisa durante 6 meses? La gente necesita decirle a Wumpus que está listo para ser fusionado… ¿y qué tan claro está que está listo? Tal vez es peligroso código de consenso. ¿Qué cosas van a necesitar un mayor nivel de revisión? ¿Qué aprobación se requiere?
Las menciones reciben correos electrónicos con estrellas, con un filtro en la bandeja de entrada de correo electrónico. Algunas personas parecen estar usando la interfaz de github. Tal vez las menciones necesitan una respuesta, como una mención ACK.
No se puede usar git blame para la construcción de nagfile. ¿A quién regañas? ¿Quién regaña? Github tiene una sugerencia de revisor. Phabricator tiene una lista de seguimiento donde notifica a los usuarios cuando un determinado archivo se cambia en un pull request.
Podrías usar una etiqueta de tamaño para indicar lo grande que es el PR.
No es una “falta de proceso” para “quién debe revisar este código”. Parece haber reglas implícitas por las que la gente que fusiona parece tener algún criterio, aunque no esté escrito formalmente en ninguna parte. Hay un umbral por encima del cual yo digo “vale, creo que puedo fusionar esto” y no está claro cuál es ese umbral para los recién llegados. No puedes tener reglas muy estrictas, como “para este trozo de código, necesitas 4 revisiones de personas cuyos derechos de voto sumen…” o lo que sea. O puedes mostrar a alguien una línea de tiempo y decir que en 3 semanas alguien revisará esto y dará una estimación actualizada. No hay forma de garantizar que alguien lo haga, en ese plazo.
Podríamos poner notas de diseño en la wiki de desarrolladores, donde ponemos las notas de lanzamiento. No hay riesgo de que las cosas se pierdan allí.
En lugar de decir a los colaboradores que este es el proceso, podríamos decir que este es un ejemplo de lo que ha sucedido en el pasado con otras peticiones, pero esto es más o menos lo que parece. Podríamos dar ejemplos históricos de cómo han ido las relaciones públicas. También se podría indicar un “embajador” con quien hablar sobre el proceso general o lo que sea. Pero no es alguien que se dice que tiene la capacidad de finalizar las cosas, sólo alguien para ayudar socialmente al usuario.
Debería haber un FAQ para las normas culturales y lo que está pasando, y ejemplos históricos. Además, no parece que mucha gente utilice la respuesta “-0”. A veces los PR se quedan porque nadie quiere pelearse con el autor.
Es básicamente un trabajo a tiempo completo para alguien tener una visión general de todas las cuestiones abiertas y PRs. Sería útil tener a una persona que en general esté al tanto de qué son esas cosas, quiénes son esas personas, en qué están trabajando, simplemente estar al tanto de qué asuntos están abiertos, y luego saber que esto cierra algunos otros tickets. Las cuestiones serían entonces más útiles. Ahora mismo supongo que la mitad de los problemas ya están solucionados. O el conocimiento de lo que ha surgido en el pasado o lo que se ha cerrado, o las personas que han abierto problemas similares, o algo así. ¿Es mejor tener una sola persona que tenga esa visión de conjunto? ¿O varias personas con esa responsabilidad? Puede que no sea realista que una sola persona se encargue de eso, pero creo que deberíamos intentarlo. Además, deberían preguntar a los desarrolladores si tiene impacto.
Si utiliza auto-cierre, a continuación, decir “Si usted piensa que esto se cerró por error, entonces por favor notifique a alguien” y que podría volver a abrir como la gente sigue trabajando en.
Vamos a ir a través de las solicitudes de extracción y hablar de ellos en persona. Tal vez sólo con un enfoque en los conceptos.Todo el mundo debe mirar a sus PRs abiertos y llegar a un plan para ello, y pedir a la gente mientras estás aquí para revisar esos. Como revisor, no hay manera de que voy a conseguir a través de todo esto y es activamente desalentador.
Rebase-needed necesita “rebase needed and then merge”- para que el rebase garantice un merge. Un cementerio muerto de ideas geniales, que ya tiene una etiqueta. Sin embargo, ¿la gente está mirando esa página?
Si algo necesita revisión y no la recibe, entonces asigna aleatoriamente a un colaborador que se haga responsable de la revisión o asigna a alguien más. Podría convertirse en una patata caliente. Te dan una patata y sólo puedes tirarla una vez. Si alguien está sobrecargado, debe decir que está sobrecargado.
Necesitamos gente que se comprometa a hacer 3-4 revisiones a la semana. El problema es la falta de revisiones cualificadas. No debemos desperdiciar el trabajo de revisión. Si hacemos el concepto ACK y una o dos revisiones… antes de que esas revisiones se queden obsoletas, entonces debería considerarse prioritario. Debería haber un compromiso para centrar la revisión en las cosas que realmente están etiquetadas como “de alta prioridad”.
¿Qué tal una etiqueta “casi listo”? Si hay alguien encargado de mantener esas etiquetas, entonces está bien. Una etiqueta “casi listo” para tu RP sería que tienes 2 acks, parece que la gente tiene otro. El concepto ACK podría ser reemplazado por una cuestión, el concepto ACK sólo debería estar en cuestiones…. no, eso crearía demasiadas cuestiones. Código sentado y pudriéndose obtener Concept ACKs es un problema; podría ser un problema tener eso.
Deberías actualizar tu comentario inicial en el PR. Nadie debería leer los 150 comentarios. Necesitas actualizar tu OP.
“Alta prioridad para revisión” necesita ser gestionado y actualizado. Necesitamos personas que revisen esas cosas cada semana. La gente ha intentado hacer procesos para esto. El proceso ha existido. Ha habido otros anteriores. Necesitamos compromiso para hacer la revisión. La solución es el compromiso, no más procesos. La gente tiene que seguir el proceso.
La lista de “alta prioridad” no debería ser autoaceptable. Deben ser cosas realmente prioritarias. Necesitas a alguien que haga el seguimiento y consiga que la gente haga sus revisiones. La idea de esto durante la reunión… ¿cuál es la prioridad del proyecto? La alta prioridad se introdujo para los bloqueadores, porque la gente divide su trabajo en sus pull requests, y algunos de ellos necesitan entrar ahí. Debería haber cierto acuerdo en que son de alta prioridad. El nombre podría cambiarse a “problemas bloqueantes” o algo así.
Si quieres que tu PR esté en la lista de alta prioridad, entonces deberías estar revisando la revisión de PR de otras personas. Tal vez un “ojo por ojo” en el que tú revisas mis relaciones públicas y yo reviso las tuyas.
¿Debería alternarse la hora de la reunión? Para que tenga una cobertura mundial completa.
De hecho, en la lista en este momento hay: cosas de redes (abiertas desde hace 2 años o algo así) pero se están haciendo; monederos externos; introducir banman; RPC; cosas de selección de monedas, un par de PRs de Matt que están reescribiendo la interfaz entre la validación y el procesamiento de red en lo que respecta a DoS; y algunos trabajos de monedero que parecen listos para ir hoy también. Hay cosas de GUI, cosas de cartera, cosas de red. ¿Podemos tener todo esto fusionado para finales de mañana? Podríamos finalmente conseguir el banman. Enfoquémonos en esto durante los próximos 2 días, y si no funciona entonces tal vez aprendamos acerca de por qué no funcionó.
¿Se eliminan cosas de la lista de revisión de alta prioridad? La intención era que si había - si se ha revisado y realmente necesita cambios antes de que se fusionó, entonces sería eliminado en la reunión de la semana siguiente, pero hasta cierto punto esto no ha sucedido. A menudo se necesita rebase, entonces se obtiene un rebase, no se elimina, pero entonces todavía necesita rebase … Creo que tenemos que arreglar esto. Solo vas a aprender a no usar esa lista si vas ahi y ves algo que sigue necesitando un rebase… entonces te anima a dejar de usarlo. Si usted no rebase y no hacer nada con la retroalimentación, entonces tiene sentido para dejarlo fuera de la lista. Pero si estuviste ocupado por 3 dias, entonces deberia desaparecer de la lista por 3 dias. Si vamos a hacer eso, es mejor que lo elimines de la lista por cortesía.
¿Recompensas de reseñas financiadas por la comunidad? El hada de las revisiones elegiría a los tres mejores revisores de la semana, y ellos recibirían el dinero.
Prioridades de desarrollo para los próximos 6-12 meses
¿En qué ha estado trabajando Matt?
Una de las conclusiones de ayer fue sacar cosas de la lista de alta prioridad más rápido. También, tal vez un nagfile para qué áreas de código corresponden a qué personas para regañar. Hay un bot de facebook que mira la culpa de git y luego menciona a la gente.
El objetivo por ahora es hablar de las prioridades de desarrollo a mayor escala. Matt tiene algunas cosas en las que está trabajando. Cory también. Ryanofsky también. Tal vez podrías explicar lo que estás tratando de lograr, qué ayuda necesitas, o lo que sea, y si hay alguna priorización que hacer entre esas cosas.
Cosas de Cory: Tengo varias cosas en paralelo. Está el refactor de la red. Creo que está casi terminado. Ya viene. Probablemente estaré… Me desaceleré mucho este último ciclo porque era un lanzamiento de características. Voy a pedir más revisiones. En paralelo, voy a estar revisando más cosas también. Tengo un proyecto de cadena de herramientas en el que estoy trabajando. Esto es gitian cosas de estilo para conseguir parte de gitian desaparecer. Quiero llegar a un estado en el que pueda ponerlo en público, antes de empujarlo por ahí, así que estoy reclutando algo de ayuda. Tengo una cosa hash UTXO que he estado socializando. Es un poco pronto para discutirlo y lanzarlo aquí. Ese va a ser mi proyecto inmediato. Es una característica interesante, y la describiré en la lista de correo pronto. Probablemente voy a tratar de reclutar ayuda en la cadena de herramientas. Necesito hacer un rebase, necesito algunas revisiones sobre eso. Hay algunos otros PRs que son más a largo plazo, y estoy tomando trozos de eso, y PRing esos lentamente.
ryanofsky: I have a lot of PRs open for review. Most of them are fairly small. I am working on two projects. One is the account label renaming refactoring thing to get rid of acccounts and replace them with labels. There’s one PR, it has a few ACKs, it’s very mechanical, but kind of big. If we can get that in, there’s another chainstate that Wladimir has that I have rebased on, that should complete the accounts label rename and getting rid of accounts. Wladimir’s is old now. The PR is 11536. It’s a straight rename. Wladimir had a big PR, and split a chunk off, then rebase it on top. That would be nice to get in, especially since we just had a release. I also have been working on process isolation and separation where GUI and node are running separately. There are 3 PRs there. Two of them are kind of similar to the account label rename. They are kind of large and these kind of refactor mechanical changes. These are just refactoring changes, that basically look for all the places where the wallet is accessing the global variables of the node, and replace those with calls, and same with GUI for accessing global variables for the wallet or the node, and these are refactoring changes. These PRs are open and they are ready for review. I am trying to get interprocess communication into better shape, I have been trying to clean up the code. This is process splitting. There might be disagreements on how to do the process splitting. Wladimir’s idea is the later PR. But the refactoring to separate the code from each other and other parts, people need to look at the code and the changes there. I think we agree at a high-level that the wallet code, like, you shouldn’t have… wrapper on a wrapper or whatever. Having a clean separation between the wallet and the node is generally a good thing, even if it doesn’t result in separating it into processes. The GUI can be made more asynchronous. The idea is that should we make the GUI more async, or is it okay to do this without doing that first? I had not made any changes to the way the GUI functions. I just made it so that you have an option to run it in a separate process and make synchronous calls. Until you split it out into a separate process, it’s not going to be any less responsive, since it’s just going through an interface. Wladimir thinks it should be made asynchronous first before splitting it out. We need to clean up the internal interfaces. The first two PRs just define the interface. The GUI code calls into the connection manager right now. The actual change there, out to review, are simple mechanical things where you can see the calls the GUI is making into the node, and into the wallet, it makes it obvious what is being called and where cleanups need to happen. Right now the code is just a big ball of mud and you need to know what is being accessed. The concern is that if the GUI is synchronous and we use IPC then it will be even slower. That’s the concern. The build default is to still use a single process. You could flip that flag but it’s not the default, in the PR.
BlueMatt: En qué he estado trabajando… mis PR tienen un montón de cosas que intentan continuar el trabajo de dividir el main. Hay un montón de cosas acerca de dividir la validación más. Tenemos una clase ficticia en la parte superior de la validación que está haciendo las cosas más lentas, así que he estado usando eso, y el comercio de la pérdida de rendimiento para otra cosa. Mediante la limpieza de validación en dos partes principales, la primera es el motor real que es la validación y luego es una especie de la cosa expuesta en la validación por lo que mantiene las cerraduras y toda esa basura. Y el backend de almacenamiento, que es flush to disk, read block from disk y todas esas cosas, y con suerte dividir todos los bloqueos entre esas dos cosas. Quiero dejar de mantener cs_main mientras que la lectura de bloques de disco, que sería bueno hacer en algún momento. Ese es el objetivo a alto nivel para la validación. Además, dividir el procesamiento… Suhas me ha dado su opinión al respecto, así que ahora mismo hay uno abierto sobre el que sería interesante recibir comentarios. En este momento tenemos este encontrar el siguiente bloque para descargar, y una de nuestras funciones más críticas para mantener el consenso para los compañeros, y utiliza una gran cantidad de estructuras de datos específicos de procesamiento de red para hacer su trabajo, y mover algo de eso en la validación, creo que sería un objetivo útil, y, esencialmente, que la interfaz se convertirá en “hola validación, tengo un compañero con una marca que creo que es X, ¿debo descargar algo y si es así qué” y podría ser no específica de nuestro protocolo p2p, pero requiere el seguimiento de un conjunto de cabecera candidato. Tengo código que hace esto, pero es algo en el corazón de la validación y algo complejo de mantener correctamente. Agradecería cualquier comentario al respecto. Como la validación se limpia más en interfaces más limpias, usted podría hacer cosas como, una cosa que quiero hacer es hacer cs_main un … bloqueo. Creo que hay un PR de PracticalSwift llamado look up block index hwich que necesita revisión. Y estoy muy cerca de hacer todos los índices de bloque de semillas const, y también cs_main podría ser más dentro de la validación, y luego cs_main podría ser utilizado antes de las pocas cosas en modo de escritura dentro de la validación en su mayor parte puede ser written…. Bloqueo compartido y bloqueo exclusivo. La mayoría de nuestros hilos no tocan cs_main en términos de escribir en él… la mayoría de nuestros hilos, sólo tenemos unos pocos conceptos de hilos como trabajadores para HTTP y RPC y cualquier otra cosa, que sólo toma cs_main para que pueda leer alguna estructura de datos y eso es todo sencillo. Y luego tenemos cosas de red que toman cs_main en modo escritura porque tienen que hacerlo. No tenemos muchos modelos de hilos. Y luego cosas de cartera.
Debería cs_main dividirse en bloqueos separados, para hacerlo más específico al contexto, en lugar de hacer que todo sea de lectura-escritura. Podría ayudar. Dividirlo es más difícil. El otro - en este momento, cs_main se utiliza principalmente para tres cosas diferentes. Se usa para proteger las cosas principales como la cadena activa, el índice de bloques, esas cosas, se usa para proteger el mempool, pero eso se entremezcla con la cadena activa. Y luego se utiliza para CNodeState que es como una locura … pero la desconexión que es super complejo, ha habido algunos intentos en él, quiero tomar otra oportunidad en él. Tener dos CNodeStates por ahora puede ser la forma correcta de hacerlo. Hacerlo de otra manera es un poco más doloroso. Y entonces puedes empezar a quitar cs_main, pero eso es un proyecto a muy largo plazo. Este es el único candidato para tomar cs_main y dividirlo entre mempool y lo que sea..
Darle al mempool su propio estado, esa era una idea que yo solía apoyar, pero es realmente difícil. ¿Qué hacer con el estado del conjunto UTXO? Tu conjunto UTXO contra el que validas y confirmas transacciones, crecerá de forma inconsistente con tu mempool. Validas la transacción no confirmada, primero, … y no puedes añadirla al mempool supongo. Si la añades al mempool, entra un bloque, se elimina una transacción conflictiva después de eso, entonces estás bien. No necesitas mucho estado UTXO del mempool. Ya tenemos código que lo extrae a un dummy y libera un bloqueo. Sin embargo, todavía tienes que sincronizarlo. Entras en un estado en el que tienes una transacción, la buscaste con el conjunto UTXO actual, la pusiste en cola para validación, entró un bloque, puso en cola un montón de eventos…
Queremos limpiar el código. Limpiar la validación para que el motor de validación, por así decirlo, la cosa que hace toda la validación y la conexión y desconexión, es una sola cosa con un almacén de disco de respaldo y un frontend que empujar las cosas en. Esto hace un montón de otras cosas más fáciles, como este cambio de PracticalSwift para hacer búsquedas de índice de bloque a través de una función para que el índice de bloque no se libera al mundo, una vez que usted tiene que, usted podría cambiar fácilmente. El término que buscas es aislamiento. Encapsular la validación es el primer paso. Encapsular la lógica p2p es un paso paralelo, y es mucho más difícil probablemente. Que utiliza CNodeState y CNode y estructuras de consenso. Vamos a arreglar esto pronto. Cory y BlueMatt han seguido sin ponerse de acuerdo sobre cómo hacerlo, y seguiremos sin ponernos de acuerdo durante mucho tiempo sobre cómo hacerlo. Pero sí, esa parte se puede arreglar. CNodeState dpeending en todo lo demás, es un enorme dolor en el culo y un cambio increíblemente invasivo. Lo he hecho en tres ramas distintas, cada vez funciona pero es terrible.
Quiero poder usar Bitcoin Core sólo para rastrear direcciones o claves. Lo más probable es que tus claves estén almacenadas en un monedero hardware. Hice un PR para esto pero descubrimos que no es lo que queríamos. El PR que hice funcionaba pero cada dirección generada era considerada una dirección watchonly, y eso no es lo que queremos. Queremos claves ismine, incluso si no tenemos la clave privada. Queremos ismine para fundrawtransaction y otras cosas. Quiero separar ismine de tener la clave privada. sipa ha escrito esto, un ismine separado.
Casi todo en el codigo, no deberia importar si realmente tienes la clave privada para algo o no. Hacer ese modo “ismine” separado es exponer el conocimiento de si la clave privada esta realmente ahi, a todo, mientras que deberia ir al reves. Tenemos el concepto de watchonly, y watchonly significa que es nuestra sin tener la clave, pero es más apropiado para cosas como, esta es una clave que participa en un multisig y yo no tengo acceso a ella, porque en realidad es la clave de mi amigo, pero quiero ver las transacciones que la afectan de todos modos. El concepto de watchonly es útil, pero debería ser ortogonal a si tenemos las claves privadas. He hecho este escrito en el que planeo trabajar.
sipa: Tengo algunas cosas de menor prioridad como la agregación de firmas es una de ellas. la encriptación p2p es una de ellas. Creo que mi prioridad ahora, en Bitcoin Core específicamente, será el monedero.
morcos: Estoy interesado en que el proyecto haga, y potencialmente podría hacerlo yo mismo, es sin hablar de cambios en el consenso, hacerlo más escalable. Cosas de rendimiento más rápido, potencialmente diferentes modelos de seguridad, hemos hablado de empezar en un modo SPV y backfilling. Me gusta la idea, pero asumir UTXO inicio para que usted no tiene que hacer IBD que también tiene una opción de backfilling. Estas cosas requieren mucha reflexión sobre la forma correcta de hacerlo y lo que significa para nosotros plantearlo y los precedentes sobre modelos de seguridad. Creo que estas deben ser las prioridades, porque podríamos perder gente corriendo nodos, y estamos haciendo que sea más difícil - Me gustaría ponernos en una posición técnica en la que si se da el caso de que tenemos que hacer un cambio de consenso para aumentar las cosas, que es menos de una cuestión técnica. Es un problema grave para el tiempo que se tarda en hacer IBD, así que vamos a trabajar en hacer todo eso mejor. Creo que asumir utxo es interesante. ¿Qué deberíamos hacer primero al respecto? Compromisos, luego hay varias formas de sincronizar el conjunto UTXO, compactación del conjunto UTXO…
Mi rastreador de semillas dns está viendo el número más alto que he visto nunca, probablemente la mayoría de ellos están en AWS, parece ser 12.000.
Además de ejecutar un nodo, también es importante utilizar un nodo. Hay un empuje cultural para ejecutar nodos sólo para hacerlo. Pero la verdadera razón debería ser ser soberano y validar las transacciones de forma independiente. Me pregunto cuántos monederos están gestionados o conectados a un nodo completo autocontrolado.
Poner en marcha un nodo completo en 5 minutos. Con asumir utxo, tal vez eso podría hacerse. ¿Y si se sincroniza un nodo completo en un portátil que se conecta/desconecta regularmente? ¿Qué tal un monedero para smartphone que se conecte a tu nodo, con una conexión autenticada?
Instale la cartera en su teléfono, QR par con su nodo en su escritorio. Y entonces está listo para ir donde quiera que vaya. También podrías emparejar tus clientes SPV lite con amigos específicos, que podrían compartir un código QR para su conexión o nodo de origen. Podrías añadir más índices opcionales.
Copiar un conjunto UTXO de un nodo a otro. No es obvio cómo hacerlo. Es fácil meter la pata. El modo de poda no es lo suficientemente completo como para hacer eso, hay casos extremos. Estaría bien obtener una cadena autenticada de un nodo antiguo o de un amigo, y simplemente sincronizar.
“Assume UTXO” es una idea similar a “assumevalid”. En assumevalid, tienes un hash que está codificado en el código, y asumes que todos los bloques de la cadena que terminan en ese hash, que esas transacciones tienen scripts válidos. Esta es una optimización para el inicio para no tener que hacer comprobaciones de script si estás dispuesto a creer que los desarrolladores fueron capaces de revisar y validar adecuadamente hasta ese punto. Se podría hacer algo similar, donde se almacena en caché la validez del conjunto UTXO particular, y es ACKed por los desarrolladores antes de actualizar el código. Cualquiera puede volver a calcular ese valor de forma independiente. Hay algunas consideraciones matizadas para esto, es una cosa diferente de assumevalid. La desventaja si metes la pata, es mayor. En assumevalid, puedes engañar a alguien haciéndole creer que el bloque es válido si no lo era, y en assumeutxo podrías ser capaz de crear monedas o algo, definitivamente hay diferentes modos de fallo. Así que hay diferentes implicaciones de seguridad aquí. Podrías usar utxo assume valid, pero podrías volver atrás y volver a comprobarlo más tarde. Pero hay matices acerca de cómo esto debe hacerse o cómo. Podrías tener nodos que exporten este valor, podrías mentirle a tu amigo supongo, pero eso da menos miedo que otras cosas.
Si quieres hacer SPV híbrido, tienes que empezar por rastrear las cabeceras candidatas, que era el PR que bluematt mencionó antes. Existe, eres bienvenido a intentar revisarlo, pero creo que es el único primer paso lógico para SPV híbrido.