“Mauro, ¡CALLA LA MIERDA! Es un error, está en el núcleo. ¿Cuánto tiempo llevas siendo mantenedor? ¿Y *todavía* no has aprendido la primera regla del mantenimiento del kernel? Si un cambio provoca que los programas del usuario se rompan, es un error en el kernel. Nunca NUNCA culpamos a los programas de usuario. ¿Qué tan difícil puede ser entender esto? -Linus Torvalds
No rompas el espacio de usuario. Ésta es la regla de oro de Linus Torvald para el desarrollo del kernel de Linux. Para aquellos de ustedes que leen esto y no están familiarizados con la naturaleza de Linux o los sistemas operativos en general, el núcleo es el corazón y el alma de un sistema operativo. El kernel es lo que realmente administra el hardware, moviendo bits entre el almacenamiento y la RAM, entre la RAM y la CPU a medida que se calculan las cosas, y todos los pequeños dispositivos y piezas de la computadora real que deben controlarse a nivel de hardware.
Cada aplicación o programa escrito para un sistema operativo tiene que interactuar con el kernel. Cuando descargas Photoshop o Telegram, todo lo que hace el programa se reduce esencialmente a llamar al kernel. “Hola kernel, toma lo que acabo de escribir, procésalo y envíalo a través de una conexión de red al servidor”. “Hola kernel, toma el cambio de color que hice en este tono, sácalo de la RAM y envíalo a la CPU para modificarlo, luego vuelve a colocarlo en la RAM”.
Cuando se cambia el kernel, de manera algo similar a Bitcoin, el objetivo principal de los desarrolladores es garantizar que las aplicaciones existentes que asumen una forma específica de interactuar con el kernel no se rompan debido a un cambio en el kernel. Suena muy familiar para Bitcoin y la necesidad de mantener la compatibilidad con versiones anteriores para las actualizaciones de consenso de la red, ¿no es así?
“En serio. ¿Qué tan difícil es entender esta regla? En particular, no rompemos el espacio del usuario con TOTAL CRAP. Estoy enojado porque todo tu correo electrónico estaba terriblemente mal y el parche que rompió las cosas era obviamente una mierda. Todo el parche es una mierda increíblemente rota. Agrega un código de error loco (ENOENT), y luego, como es tan loco, agrega algunos lugares para solucionarlo (“ret == -ENOENT ? -EINVAL : ret”).
El hecho de que luego intentes poner *excusas* para romper el espacio del usuario y culpar a algún programa externo que *solía* funcionar, es simplemente vergonzoso. No es así como trabajamos. Arregle su maldita “herramienta de cumplimiento”, porque obviamente está rota. Y arregle su enfoque de la programación del kernel”. -Linus Torvalds
Linux es uno de los proyectos de código abierto más importantes, si no el más importante, del mundo entero. Android se ejecuta en Linux, la mitad de la infraestructura backend (si no mucha más) se ejecuta en Linux. Sistemas integrados que controlan todo tipo de cosas computarizadas en el fondo de tu vida que ni siquiera considerarías ejecutar en Linux. El mundo literalmente funciona con Linux. Puede que no se haya apoderado del escritorio como muchos usuarios autistas de Linux querían que sucediera, pero silenciosamente se comió casi todo lo demás en segundo plano sin que nadie se diera cuenta.
Todas estas aplicaciones y programas que la gente usa en el curso de su vida diaria dependen de la suposición de que los desarrolladores del kernel de Linux no romperán la compatibilidad con versiones anteriores del kernel para permitir que sus aplicaciones continúen funcionando. De lo contrario, cualquier aplicación que ejecute debe continuar usando versiones anteriores del kernel o asumir la carga de modificar sus aplicaciones para interactuar con un cambio importante en el kernel.
El camino más probable hacia el éxito de Bitcoin es un camino muy similar: simplemente convertirse en una plataforma sobre la que se construyen aplicaciones y herramientas financieras de tal manera que la mayoría de las personas que las usan ni siquiera se darán cuenta o considerarán que “Bitcoin se comió el mundo”. De manera similar a Linux, la regla de oro de “No romper el espacio de usuario” se aplica diez veces. El problema es que la naturaleza de Bitcoin como sistema de consenso distribuido, en lugar de un único núcleo local ejecutándose en la máquina de una persona, cambia radicalmente lo que significa “romper el espacio de usuario”.
No son sólo los desarrolladores los que pueden romper el espacio de usuario, los propios usuarios pueden romper el espacio de usuario. Todo el último año de tokens Ordinales, Inscripciones y BRC-20 debería demostrarlo definitivamente. Esto ofrece un dilema muy serio cuando se analiza el mantra de “No romper el espacio de usuario” desde el punto de vista de los desarrolladores. Por mucho que a muchos Bitcoiners en este espacio no les gusten los Ordinals y estén molestos porque sus propios casos de uso están siendo interrumpidos por el tráfico de red que los usuarios de Ordinals están creando, ambos grupos son usuarios.
Entonces, ¿cómo afrontan los desarrolladores este problema? Un grupo de usuarios está dividiendo el espacio de usuario para otro grupo de usuarios. Promulgar un cambio que impida el uso de Ordinales o Inscripciones viola explícitamente los mandatos de no romper el espacio de usuario. Estoy seguro de que la gente quiere decir “¡Taproot rompió el espacio de usuario!” en respuesta a este dilema, pero no fue así. La activación de Taproot y la posibilidad de que los datos de los testigos sean tan grandes como el tamaño completo del bloque no rompieron ninguna aplicación preexistente o usos creados sobre Bitcoin. Todo lo que hizo fue abrir la puerta a nuevas aplicaciones y casos de uso.
Entonces, ¿qué hacemos aquí? Intentar filtrar, o romper mediante un cambio de consenso, las personas que crean Inscripciones o intercambian Ordinales es violar fundamentalmente la máxima de “no romper el espacio de usuario”. No hacer nada permite que una clase de usuarios rompa el espacio de usuario de otra clase de usuarios. Fundamentalmente no hay solución a este problema excepto violar la regla de oro, o implementar una funcionalidad que permita a la clase de usuarios cuyo espacio de usuario ahora está roto adaptarse a las nuevas realidades de la red y mantener una versión viable de sus aplicaciones y uso. casos.
No romper el espacio de usuario de Bitcoin es de vital importancia para su éxito y funcionalidad continuos, pero no es tan simple como “no cambiar nada”. Los cambios dinámicos en el comportamiento del usuario, que no requieren ningún cambio en el protocolo en sí, pueden tener al final del día el mismo efecto que un cambio importante en el protocolo. ¿Se supone que los desarrolladores deben elegir qué espacio de usuario de las aplicaciones está roto para mantener el de otra aplicación? Yo diría que no, e iría más allá al decir que cualquiera que defienda tal comportamiento por parte de los desarrolladores les exige que actúen de manera irresponsable y de una manera que perjudique a los usuarios del sistema. Entonces, ¿cuál es la respuesta aquí?
No hay respuesta excepto seguir adelante y continuar agregando mejoras al protocolo que permitan que las aplicaciones que se ven afectadas por el comportamiento de ciertos usuarios funcionen en presencia de cambios emergentes en el comportamiento de los usuarios. De lo contrario, está pidiendo a los desarrolladores que descarten la regla de oro y jueguen efectivamente a hacer reyes con respecto a qué casos de uso son viables para construir sobre Bitcoin.
Si seguimos ese camino, ¿qué estamos haciendo realmente aquí? No puedo decirles qué estamos haciendo en ese momento, pero sí puedo decirles que ya no se trata de construir un sistema distribuido y neutral.
