🇪🇸 Teoría vs Ingeniería en Criptomonedas | Charles Hoskinson y Lex Fridman | Lex 19 Jun 2021

:es: Transcripción al español de “Theory vs Engineering in Cryptocurrency | Charles Hoskinson and Lex Fridman”

Publicado en el canal de Youtube Lex Clips el 19 de Junio de 2021

Enlace a la versión doblada al español


Lex: Vayamos a la diferencia entre teoría de ciencia de la computación e ingeniería de software. No sé si vos trazás una distinción, pero si miramos el mundo de computadoras, ¿hay una diferencia entre teoría, cosas que podés decir formalmente, y la implementación pragmática de esa teoría en sistemas reales que la gente utiliza?, que supongo yo llamaría ingeniería de software.

Charles: El ingeniero está obsesionado con el dominio de “¿qué querés lograr, y para quién los estás logrando?”, así que viven en el mundo de la gente, si son buenos ingenieros, y dicen “bien, ¿cuál es la experiencia, cómo vamos a utilizar esto, por qué vamos a hacer esto, cuál es la aplicación comercial, cuál es la aplicación no comercial?, y colectas todos estos requisitos de negocios. Una vez que hiciste todo eso, cuanto mejor trabajo hayas hecho, es más evidente cómo aplicar los juguetes y herramientas de ciencia de la computación y otras cosas como esas para de hecho resolver eso. El punto de la teoría de la ciencia de la computación, desde el dominio de la ingeniería de software es como que puede decirte dónde están tus rieles. No hará programas perfectos, no hay tal cosa como esa, pero puede darte una buena noción y sentido que tu programa tiene algunas propiedades deseables, quizás podés probar que puede terminar si estás lidiando con programas totales o quizás pueda probar que no vas a tener una sobrecarga de buffer, que no va a dividir por cero en algún lugar, o algo así, que no ocurrirá algún evento que causará una falla catastrófica en tu sistema.

Pero siempre está esta exploción combinatoria entre lo que podés testear y pensar, y lo que de hecho podés codificar. Así que las cosas del lado izquierdo viven en un universo diferente, hay algo significativamente más grande ahí. Y las herramientas del lado derecho, tenemos testeo basado en propiedades, solucionadores SAT, tenemos todas estas cosas geniales aquí, en la tierra de métodos formales, y en la tierra de las ciencias de la computación. Pero sólo hay un pequeño sub conjunto de cosas que de hecho te dan buenas respuestas al respecto.

Así que el balance de las dos cosas es básicamente decir “bueno, ¿qué es lo que te importa y qué estás de acuerdo en tirar?, ese es el arte de ingeniería y construir este tipo de cosas. En criptomonedas lidiamos con estos complejos sistemas distribuidos que tienen criptografía, teoría de juego y actores bizantinos. Así que el balance ahí es decir “¿qué es lo que no puede fallar en ese sistema?”, y ese es el tipo de cosas que querés aplicar con el conjunto de herramientas más pesado que tengas, porque cuando esa cosa falla, o tenés una pérdida de billones de dólares, privacidad y potencialmente incluso vidas, dependiendo cómo son adoptados estos sistemas. Pero luego otras cosas, “¿qué es lo que puede fallar, está bien si el bloque no se realiza cada tanto, está bien si aumenta tu latencia, o tu red de repente se vuelve asincrónica, te desconectás, tenés que reiniciar la computadora o algo así”. Eso probablemente está bien, es un inconveniente y carga para el usuario. Y si tratás de seguir esa cola terminarás pasando diez años persiguiendo fantasmas, mientras tanto, todo el mundo avanza.

Así que realmente es encontrar el balance entre los dos, y lo que es realmente es hermoso es que las herramientas de métodos formales mejoraron tanto durante los últimos 20 años en particular, mayormente por altas inversiones de Microsoft, Google, grandes universidades, porque estos muchachos están construyendo estos sistemas gigantes, si mirás Googleplex o lo que tiene Amazon u otros. Tienen tanto valor, tantos usuarios, tantas cosas ocurriendo, ninguna persona puede mantener eso en su cabeza. Estás hablando de sistemas que quizás tengan 10 millones de líneas de código, 15 millones de líneas de código, millones de nodos conectados, procesos fallidos ocurriendo todo el tiempo, hackers rompiendo en base regular. Cuando estás tratando de modelar eso, tratando de preguntarte ¿qué garantías formales y propiedades puedo obtener para simplificar este sistema tanto como sea posible? Así que en vez de que la aplicación de métodos formales te desacelere, en muchos casos de hecho reduce masivamente tu tiempo limpiando errores y tu habilidad dónde ocurren los errores. En algunos casos no podés encontrar dónde ocurren los errores dentro de estos masivos sistemas concurrentes.

Y decís, ¿a dónde están yendo las criptomonedas?, estamos hablando de la misma cosa, pero estamos hablando de un entorno de operación mucho más hostil, donde en vez de ser ejecutado en un centro de datos prístino en California, está corriendo en tu teléfono celular, en el teléfono celular de tu mamá, de tu papá, está corriendo en alguna computadora en Mongolia que podría tener buena internet el Martes pero no ninguno de los otros días. Así que cuando vivís en ese tipo de entorno realmente necesitás pensar cuidadosamente acerca de toda una nueva clase de protocolos, y necesitas pensar cuidadosamente acerca de toda una nueva clase de herramientas y técnicas para testear la fiabilidad de esos sistemas y necesitás separar el mundo y decir, ¿qué es de alta garantía y no puede fallar, porque si falla la gente pierde dinero, y qué es de baja garantía y está bien si eso se desmorona? La otra cosa que mencionaré es que hay incentivos financieros perversos en nuestra industria. Porque la realidad es que cuando algo explota, usualmente la gente que explotó esas cosas recibe un pago de antemano. Así que en lo que se están focalizando es en tiempo al mercado, velocidad al mercado, sacar tokens y hacerlos líquidos. Luego viene la gente, los compra, pero si hay un error en un protocolo DeFi, probablemente será descubierto seis meses más tarde o algo así, ¿si explota quién sufre?, los usuarios.

Lex: A la gente que creo eso ya se le pagó.

Charles: Exactamente, por eso le pagás al muchacho que rompe el software para que dure tu tren, y te aseguras que suba al tren todos los días.