Share this article

Revisar código es tedioso: Preguntas y respuestas con Andrew Chow, mantenedor de Bitcoin

Descubrió Bitcoin en la preparatoria mientras buscaba formas de pagar sus videojuegos favoritos. Ahora revisa y mejora el código de Bitcoin para ganarse la vida. A veces es aburrido y tedioso, pero lo hace de todos modos. Alguien tiene que hacerlo.

Pocas personas comprenden los problemas técnicos clave que enfrenta actualmente la Criptomonedas dominante del mundo. Andrew Chow es ONE de ellos.

Chow es ONE de los cuatro “mantenedores” de CORE de Bitcoin (o simplemente CORE), el software más popular para conectarse a la red Bitcoin .

Продолжение Читайте Ниже
Don't miss another story.Subscribe to the The Protocol Newsletter today. See all newsletters

Los mantenedores revisan los cambios en Bitcoin CORE , conocidos como "commits", que son enviados por otros desarrolladores de Bitcoin como "pull requests" o "PR". Chow y otros mantenedores aprueban o integran dichos cambios en el código fuente de Core. La revisión de código es crucial para garantizar que no se integre código con errores.

El proceso es transparente y, a medida que Chow examina las confirmaciones,transmite en vivo el proceso en Twitch.

Chow es un gamer de corazón y solo empezó a usar Bitcoin en la preparatoria para pagar videojuegos que de otra manera no podría permitirse. Sus padres no le dieron una tarjeta de crédito, ni le abrieron una cuenta bancaria, ni siquiera le dieron una mesada. Recurrió al trabajo freelance. Foro de BitcoinTalk y comenzó a escribir código a cambio de Bitcoin (BTC).

Chow, quien dice que ahora tiene veintitantos años, recibe un salario como ingeniero en la empresa de infraestructura de Bitcoin Blockstream, donde además de algunas tareas corporativas, su principal prioridad es trabajar en Bitcoin CORE.

Afirma que la revisión de código es ONE de los mayores desafíos que enfrenta Bitcoin hoy en día. La mayoría de los desarrolladores de CORE están entusiasmados con la creación de código para nuevas funciones, pero pocos disfrutan de la tarea más rutinaria de revisar el código enviado por sus compañeros. Chow afirma que es necesario que más Colaboradores se centren en la revisión de código para abordar las más de 300 solicitudes de registro (PR) en Core. repositorio de GitHubLa comunidad tiene unaClub de revisión de relaciones públicas de Bitcoin CORE que se reúne semanalmente para ayudar a los nuevos Colaboradores a Aprende sobre el proceso de revisión.

Chow aceptó una entrevista con CoinDesk en el Avanzando Bitcoin Conferencia en Londres. Explicó por qué la revisión de código es tan crucial, explicó lo que hacen los Colaboradores de Bitcoin CORE a diario y opinó sobre el debate actual sobre op_vault y Speedy TrialAquí hay una transcripción parcial de esa entrevista.

CoinDesk: ¿Cómo descubriste Bitcoin?

Andrew Chow: Cuando era más joven, en la secundaria, no tenía cuenta bancaria porque era menor de 18 años. Mis padres no me abrieron una . No tenía tarjeta de crédito, ni siquiera una tarjeta de crédito supervisada, y no tenía mesada. Pero Vapor Vendía juegos por Bitcoin. Si juegas en PC, puedes descargar Steam, que tiene prácticamente todos los juegos.

Además, enpurse.ioPodrías vender Bitcoin por cosas. Bueno, quería jugar videojuegos. Quería comprarlos. Bueno, no me importa la piratería, pero piratear cosas es un poco sospechoso. No sabes qué estás descargando. Podría ser malware.

Pensé: «Esto del Bitcoin es completamente electrónico. Quizás pueda usarlo para comprar juegos, pero ¿cómo consigo Bitcoin? Quizás pueda trabajar y que me paguen en Bitcoin».

Conozco a algunas personas que hicieron eso. Así fue como aprendí a programar. Entraba en BitcoinTalk y la gente decía: «Te pagaré lo que sea por escribirme un script que haga esto».

Bueno, eso parecía bastante sencillo. También tenía un amigo en el instituto. Me dijo: «Oye, ¿has oído hablar de Bitcoin ? Creo que te podría gustar». Definitivamente compraba drogas con Bitcoin.

Así fue como me inicié en Bitcoin. Y finalmente pensé: "Bueno, estoy usando esta billetera y me encuentro con estos problemas. Sé claramente cómo escribir un programa. Quizás pueda solucionar este problema". Así fue como me metí en el desarrollo.

Estaba manejando esta cosa llamadaArsenalQue básicamente no tenía mantenimiento. O sea, todavía lo mantiene una ONE persona, así que apenas.

Para cuando lo usaba, era un desastre y no siempre funcionaba. Descubrí que algunos de los problemas que ocurrían en Armory se debían a acciones de Bitcoin CORE . Bitcoin que empecé a investigar Bitcoin CORE y a preguntarme qué estaba haciendo. Bitcoin CORE tiene un error que nos está causando un error.

Armería estaba haciendo algo no recomendado: leer los archivos de bloque directamente desde Bitcoin CORE ; no se supone que se deba hacer eso. Cuando cambiaron el formato, todo se averió.

Estaba intentando conciliar ambas cosas, pero Armería simplemente desapareció de mi mapa. Así fue como pasé a Bitcoin CORE. Finalmente, dejé de trabajar en Armería porque logré más en CORE.

Ayer hablamos sobre la proporción de Colaboradores de Bitcoin que revisan código y de Colaboradores que lo escriben. ¿Podrías compartir tu opinión al respecto?

Nuestro principal obstáculo en Bitcoin CORE ha sido la revisión. Tenemos más de 300... Relaciones públicasEstán abiertos y necesitan revisión. Ya sea para asegurar que el código sea correcto o simplemente para preguntarse, "¿Realmente queremos este cambio?".

El problema con cada solicitud de relaciones públicas es que suele ser escrita ONE persona, pero necesitamos que varias personas la revisen, la aprueben o dejen comentarios. Por lo tanto, necesitamos más revisores que redactores, pero así no funciona.

Personalmente, la revisión de código me parece un BIT aburrida. Es un poco molesta y puede llegar a ser un poco tediosa. Pero aun así la hago. Supongo que es como un mal necesario y es porque no me divierte. Si la hago demasiado, empiezo a sentir que me agotaré porque ya no la disfruto.

Así que hay que encontrar un equilibrio entre escribir código y revisarlo. Es un dilema. Necesitamos más revisores que programadores, pero ¿cómo se llega a ser lo suficientemente competente para revisar código si no se escribe? Es un dilema.

Estamos en un mercado bajista y organizaciones como Brink, que financian el desarrollo de Bitcoin , afirman que la financiación ha disminuido aproximadamente un 50 %. ¿Por qué debemos pagar a los Colaboradores y desarrolladores de Bitcoin ?

Básicamente, todo software tiene errores. Siempre habrá errores que encontrar y errores que corregir. Eso es simplemente mantenimiento general del software que debe realizarse.

E incluso entonces, el software actual no puede durar para siempre. Los sistemas operativos evolucionarán, al igual que las bibliotecas, y cambiarán. Con el tiempo, el software simplemente dejará de compilarse en una computadora; podría incluso dejar de funcionar. Por lo tanto, es necesario un trabajo constante para KEEP actualizado.

Así que siempre hay cosas que actualizar, incluso sin nuevas funciones. Pero hay nuevas funciones y queremos mejorar Bitcoin. No solo las reglas de consenso, sino también cómo retransmitimos las transacciones y qué tipo de transacciones aceptamos. grupo de memoriay el protocolo peer-to-peer.

Puede haberDoS Vectores que queremos corregir o cambiar y que quizá aún no se hayan descubierto. Siempre hay algo.

Si soy un nuevo colaborador del CORE , ¿cuáles son algunos de los problemas más importantes que necesito conocer?

Actualmente existen una serie de problemas, como por ejemplo:ataques de inmovilización, que están bastante bien documentados. Parece que ONE los explota, pero eso no es razón para no corregirlos.

Se ha trabajado mucho en el mempool: cómo y qué transacciones se aceptan en el mempool, qué métodos existen para...aumento de tarifas, y cosas así. Es relevante paraIluminacióny otras redes [de capa 2].

¿Qué es un “ataque de inmovilización”?

Si ambos abrimos un canal Lightning juntos, puedo hacer que nunca aumente la comisión de esa transacción. Así, puedo mantenerla con una comisión baja perpetua y nunca se mine para luego intentar gastarla dos veces.

Hay muchos ataques que se pueden realizar con las reglas de la Regulación de mempool. Están documentados en la lista de correo y definitivamente son problemáticos. Si alguien intentara explotarlos, sería molesto, pero no creo que hayamos visto a nadie intentarlo.

Todavía queremos arreglarlos y se ha trabajado mucho en hacer mejoras para que no tengamos estos ataques de fijación, o al menos, si quieres fijar una transacción, será muy costoso.

Ayer también hablamos de op_vault y Speed Trial. Ha habido cierta tensión en torno a la recomendación de James O'Beirne de implementar op_vault con Speed Trial. ¿Algún comentario?

Con una propuesta como ésta, el despliegue debería ser lo último en lo que pensar.

Algunas ideas sobre cómo implementar las cosas son, por alguna razón, polémicas. Si se desea debatir la propuesta, incluir la implementación en ella puede desbaratarla.

Así que creo que James probablemente se equivocó al poner eso.Raíz principal La sección de implementación no se definió hasta después de Taproot. Los cambios de código se integraron en Bitcoin CORE , pero no se activaron. No es inusual simplemente decir que nos ocuparemos de la implementación después de determinar qué queremos que sean los cambios de código.

Speedy Trial fue un experimento para Taproot. Hemos probado diferentes métodos de implementación a lo largo de los años con distintos grados de éxito.

Frederick Munawa

Frederick Munawa fue reportero de Tecnología en CoinDesk. Cubrió los protocolos blockchain, con especial atención a Bitcoin y sus redes adyacentes. Antes de trabajar en el sector blockchain, trabajó en el Royal Bank of Canada, Fidelity Investments y otras instituciones financieras globales. Tiene formación en Finanzas y derecho, con especialización en Tecnología, inversiones y regulación de valores. Frederick posee unidades del fondo CI Bitcoin ETF por encima del umbral de Aviso legal de $1,000 de Coindesk.

Frederick Munawa