Transcripción al español de un fragmento de “Surprise AMA November 29th, 2019”
Del minuto 10:45 al 23:20 del video original
Publicado en el canal de Youtube de Charles Hoskinson el 29 de Noviembre de 2019
Agradecemos la contribución del buscador AMA de adatainment.com por ayudar a encontrar preguntas relevantes
Enlace a la versión doblada al español
Esta es una buena pregunta de Darko. A menudo se abordan las lecciones aprendidas de las decisiones tomadas en los últimos cinco años. ¿Qué una o dos cosas se destacan que hicieron más fuerte tu empresa hoy en día?
El problema con donde empezamos es que estábamos en lo correcto y equivocados. Estábamos en lo correcto desde un punto de vista moral donde la realidad es que el espacio de las criptomonedas en 2015 tenía un enorme potencial pero con falta de rigor. No había mucha ciencia seria, no había mucha ingeniería sería, todo estaba en el espacio de los hackers y esto es grandioso para el software de código abierto y asombroso para aplicaciones y básicamente startups, esperas esto en el comienzo. Pero el problema es que estamos lidiando con conceptos muy complicados como el desarrollo de protocolos, criptografía, sistemas distribuidos y esas cosas no se comportan muy bien en entornos Bizantinos cuando no han sido seriamente diseñados por gente seria y terminas lidiando con las consecuencias de decisiones de diseño pobres a lo largo de un tiempo. Como internet, por ejemplo, si miras lo que está pasando con Quick, la última versión de TLS, hay mucho mérito y potencial y dices "wow, si tuviéramos esto, si fuera generalizado, internet sería significativamente mejor y Vint Cerf y Bob Khan serían las primeras personas en decirte acerca de todos los errores que cometieron con internet y en retroprospectiva había cosas que simplemente no podían imaginar. Por ejemplo, todas las computadoras eran grandes, ruidosas y caras, este concepto de una computadora móvil que puedes llevar contigo en tu bolsillo y siempre está conectada sin cable, era ciencia ficción para ellos. Así que no diseñaron protocolos que estaban concebidos para estos dispositivos y porque no los han diseñado, tuvimos que hacer parches de mono para que funcionen bien en el sistema y nunca es la mejor de las experiencias. Una de las cosas que hicimos en IOHK es decir, pensemos muy muy muy profundamente acerca de todo, por ejemplo el modelo de contratos inteligentes. El problema con la idea de la computadora mundial es que la gente dice “voy a reemplazar Amazon, Microsoft, Azure, reemplazaré Rackspace y Digital Ocean con esta infraestructura descentralizada que de alguna forma tendrá la misma experiencia de usuario y funcionará y es imparable, inmutable, resistente a la censura, bla bla bla y es autosustentable” es como el mayor servidor en la nube. Así que el Dapp, el contrato inteligente está atentando reemplazar tu aplicación de teléfono celular tradicional, aplicación web y ejecutarla en esta infraestructura. Esta fue la idea hipotética y filosófica que comenzamos con Ethereum, pero cuando haces investigación tienes que pensar acerca de ello y la realidad es que tu tienes tu libro contable y tienes esta especie de puente y luego tienes el mundo convencional, los servidores, las notebooks, los clientes, etc y el libro mayor tiene una colección de capacidades que llamamos capacidades Defy, yo quiero emitir un activo, quiero tener un oráculo que me diga algo acerca del mundo externo, necesito una generación de números al azar, necesito un reloj, necesito un lugar seguro para almacenar datos auditables como un hash o algo así, donde puedo garantizar que tiene estampación de fecha y es inmutable, ok? Así que hay una colección de capacidades que el libro mayor ofrece nativamente.
Luego, tienes código que puedes escribir, esta fue la magia del estilo de enfoque Ethereum, que ahora hace hacer más a ese libro contable, tanto para ti como para todos, porque es un sistema abierto, así que estás conectando nueva funcionalidad ahí. Ahora, el punto es que esa funcionalidad, esa lógica de negocio, es un subconjunto del otro lado, de las cosas que quieres hacer aquí.
Así que esta es tu aplicación, puede ser Crypto Kitties, puede ser un Uber descentralizado o Airbnb y la realidad es que esa infraestructura que escribiste ahí mayormente continúa viviendo en servidores Amazon, mayormente continúa viviendo en servidores Microsoft, etc. Y se está comunicando a través de ese código puente a estos servicios que el libro contable está proveyendo. Ese es el modelo que tiene mucho más sentido, en cadena, fuera de cadena. Y tienes fuertes garantías de que esos servidores siempre estarán arriba y disponibles y se comportarán del modo en que planeaste que se iban a comportar y son resistentes a la censura, pero el lado izquierdo es tu aplicación, ese es tu modelo de negocio, esa es tu compañía y esa es tu cosa. Este matrimonio entre estos dos es donde el espacio está en la actualidad, la computadora descentralizada en el cielo requiere recursos computacionales subcontratados, requiere prueba de trabajo útil, requiere todo tipo de cosas para que eso de hecho tenga sentido, incluyendo almacenamiento descentralizado, etc. Y simplemente no estamos ahí com industria, quizás en 2025, 2030, 2040 lleguemos ahí y será una cosa competitiva para infraestructuras centralizadas pero no estamos ahí como industria. Pero estamos ahí con esta idea de libros contables que tienen capacidades que son aumentadas por el usuario con código puente al código fuera de cadena, siendo una aplicación de nodo o algo así.
Una de las primeras lecciones que aprendimos como compañía fue una lección que tuvimos que reducir las cosas, tenemos todos estos enfoques diferentes, podemos ser EVM, IELE, podemos hacer cosas KSBC, podemos hacer Plutus con UTXO extendido, hay DSLs que podemos escribir, por ejemplo Marlowe es un DSL financiero, también podemos hacer un DSL legal, hay siete criterios de contratos, queremos ponerlos todos juntos en un marco legal abierto y hacer un DSL legal que te permita tener un contrato tradicional y programarlo. Así que hay muchas cosas que puedes hacer, pero hay que saber dónde cortar y decir “este es el 1.0, esto es suficiente”.
Esa ha sido una gran lección para nosotros, es una lección de producto, una lección de gestión de proyecto, una lección de velocidad de software, una lección de riesgo recompensa, una lección de complejidad arquitectónica y nos tomó años llegar a un punto en donde aprendimos a hacer esas cosas bien.
Otra lección que aprendimos es el valor de usar plataformas titulares. Yoroi, en muchos respectos ha sido el producto más exitoso del ecosistema Cardano y eso no es porque es el mejor código o tiene ciertas capacidades que están tan por encima de cualquier otro. En realidad es bastante simplista, pero, tiene una hermosa experiencia de usuario, que la mayoría de nuestros usuarios necesita, se instala en un clic, es muy fácil de usar, es muy fácil restaurar una billetera y simplemente funciona, está ahí. Y cuando es actualizada, se actualiza automáticamente y tiene una infraestructura común para Linux, Windows y Mac. Así que hay una lección ahí, tienes que balancear la infraestructura y el deseo de innovación y la riqueza de lo que estamos tratando de desplegar con el hecho de la mayoría de la gente todavía está atada a experiencias tradicionales y este es un gran desafío.
Así que esa es la otra lección que diría, fuera del “¿dónde cortamos, cuánto queremos innovar?”, también debemos enfocarnos fuertemente en el usuario. Así que en 2019 comenzamos a contratar un montón de gerentes de producto como Nick, Aparna y otros y comenzamos a decirles “el usuario primero, las experiencias primero” y haremos el camino hacia atrás al backlog de producto y lo que la tecnología tiene que hacer, a dónde tenemos que ir. Ese ha sido un gran cambio cultural porque ha sido al revés para nosotros los científicos y los ingenieros que han estado liderando el show en la mayor parte del tiempo. Un montón de cosas que hicimos, un montón de las prioridades que tuvimos estaban basadas en elegancia o precisión, estaban basadas en innovación, ¿por qué no?, teníamos un mandato para innovar, un mandato para hacer investigación, un mandato para hacer las cosas de forma diferente. Era un ambiente asombroso para los ingenieros y el péndulo ahora se moviendo en la otra dirección donde estamos pensando en comercialización, producto, marketing, el cliente. El gran desafío para mí como CEO en 2020 será encontrar el alma de la compañía, mantener eso derecho, siempre seremos una asombrosa compañía de ingeniería e investigación, siempre seremos un lugar para que ingenieros e investigadores hagan el mejor trabajo de sus carreras, pero ahora tenemos que focalizarnos con un láser para que ese trabajo se materialice en cosas que beneficien a ustedes los usuarios.
Por ejemplo, estamos pensando muy profundamente en Halo como tecnología, el concepto de Snarks recursivos. No porque estas cosas son elegantes matemáticamente o haces cosas realmente geniales, sino porque las consecuencias para los usuarios, en particular para los clientes móviles son profundas, básicamente obtienes algo que funciona en un teléfono celular que tiene el mismo nivel de seguridad que un nodo completo y simplemente funciona, está ahí. Y hay tanto que podríamos hacer con eso como primitivos criptográficos en nuestro sistema. Este es un ejemplo en donde investigación densa, hermosa, elegante, que es tecnología de punta, que requiere la utilización de métodos formales, sino tenemos un estilo de arbolito de error, puede de alguna forma ser aplicada a nuestro ecosistema y repentinamente tu cliente de teléfono celular es tan bueno como el nodo completo en términos de seguridad.
Estos son los tipos de ganar ganar que estamos buscando, ese matrimonio entre el foco en el consumidor del producto y lo que tradicionalmente estábamos haciendo en tecnología. También aprendimos que debíamos hacer un mucho mejor trabajo explicandonos a nosotros mismos. Uno de los hilos de Reddit más descorazonadores que he visto últimamente fue en el Reddit Haskell, la gente estaba tan emocionada de que hayamos lanzado la última versión de Cardano, cuatro repos eran para el nodo uno Cardano y fue como una reescritura completa, nos pasamos un año en esta cosa, usamos métodos formales en esta cosa. Es una pieza de software asombrosa y más de treinta desarrolladores Haskell realmente talentosos han empeñado un año de sus carreras profesionales escribiendo este software y haciéndolo excepcional y no escatimaron en ningún detalle. Escribieron cientos de páginas de especificación, usaron Quick Check, usaron cantidades masivas de pensamiento dentro de la arquitectura y el diseño. Los tipos son perfectos, la lógica es perfecta, es software asombroso. Yo argumentaría que es el mejor software en nuestra industria. Y luego en el Reddit Haskell, vemos una persona que trabaja en Kadena, criticó la ICO Cardano años atrás, apuntó a Cardano Docs que ni siquiera había sido escrito por este equipo y dice que no hemos hecho contribuciones significativas. Hicimos contribuciones con GHC GS, todos los días tenemos a alguien que trabaja tiempo completo compilando Haskell en JavaScript. Hemos escrito un montón de librerías, mejoramos librerías como el estado ácido por ejemplo, hemos hecho grandes mejoras del lado Devops, compilación cruzada del código Haskell. Hemos hecho enormes cantidades de contribuciones a este serio proyecto, de compilación Haskell a ensamblaje web, lo que traerá Haskell al explorador. Le mostramos a la gente cómo escribir aplicaciones Haskell de producción que trabaja en Windows para gente de todos los días y trabaja con el mismo perfil de rendimiento y memoria que las aplicaciones C++, el delta es insignificante ahí.
Esto hace a Haskell no un lenguaje académico sino un lenguaje que deberías considerar para escribir tus aplicaciones como emprendedor, rápidamente y correctamente. Estoy increíblemente orgulloso de ese trabajo, pero por alguna razón, hay algunos miembros de la comunidad Haskell que piensan que está perfecto decir lo opuesto. Así que esa es una lección que aprendí, que realmente debemos ser buenos comunicando, siempre tuvimos esta idea, especialmente entre gente bien aprendida o ingenieros y científicos de que el trabajo que hacemos es evidente por sí mismo, es obvio que hemos hecho un trabajo asombroso con prueba de participación, es obvio que hemos hecho un asombroso trabajo de ingeniería, etc. Y lo que encontramos es que no lo es, así que trabajamos muy de cerca con Tim y ya comenzamos un montón de iniciativas, por ejemplo, estamos escribiendo una completa serie de artículos de Ouroboros y básicamente vamos a empezar desde el principio y haremos nuestro camino en ese viaje que nosotros atravesamos y claramente articular por qué Ouroboros soluciona el problema de la prueba de participación y hacer esto para la gente, para tener algo ahí. También vamos a poner un artículo dedicado acerca de ataques en prueba de participación como nada en participación o ataque de largo alcance, etc y claramente articular por qué Ouroboros derrota estos ataques en particular, ese es un hilo que hemos hecho y habrá otro acerca de Plutus, otro acerca de lo que hemos hecho del lado de la ingeniería, etc. Para que la gente puede realmente entender que el dinero fue bien gastado y el tiempo fue bien empeñado y realmente entender las ganancias que nosotros como ecosistema y proyecto hemos tenido, así que esas son algunas de las lecciones que he aprendido.