Ayer, cuando estaba en Binance, no tenía intención de investigar nuevas monedas. Mi dedo se deslizó sin querer hacia la entrada de Alpha y vi que ROBO apenas había salido hace unos días, y su volumen de transacciones ya estaba casi a la par de su capitalización de mercado. Este tipo de mercado es muy fácil de llevar a las personas a las emociones, pero yo prefiero considerar la popularidad como un indicador, no como evidencia. La exposición en el intercambio y las actividades realmente pueden encender la atención, pero la atención no resolverá los problemas reales. La economía de los robots suena muy grande, pero al implementarse a menudo se queda atascada en los aspectos más básicos: ¿se realizó la tarea o no? ¿Cómo se llevó a cabo? ¿Quién lo valida? ¿Cómo se liquidan los pagos? ¿Cómo se responsabiliza a alguien en caso de un problema? ¿Quién asume los costos de retrasos y fricciones? Si desglosas todo esto, te darás cuenta de que la billetera es solo el último botón; todo lo anterior son problemas difíciles.
Prefiero explicar de manera más clara por qué es tan difícil. Los robots no son botones en una página web; en el mundo real, recorren sus trayectos, y el ruido de los sensores, la deriva en la localización, las desconexiones de red, el envejecimiento del hardware y los cambios ambientales son todos fenómenos normales. En la cadena, por naturaleza, solo podemos ver las transacciones y los cambios de estado; no podemos saber si el robot realmente movió una caja, recorrió una línea o cargó su batería. Si las recompensas se vinculan demasiado estrechamente a ciertos indicadores que pueden subirse a la cadena, los emisores encontrarán la manera más económica de “actuar” según esos indicadores. Ya hemos visto en DePIN los viejos trucos de duración en línea y de marcado de coordenadas; si aplicamos esos mismos métodos a los robots, la situación será aún más complicada, porque el mundo real tiene muchas más suturas y es mucho más difícil sellarlas todas de una sola vez.
Por eso entiendo que el núcleo de lo que Fabric quiere resolver no es simplemente ponerle una moneda a los robots, sino dotar a las tareas reales de dos piezas de infraestructura: identidad y liquidación. La identidad no consiste solo en tener una dirección; debe permitir que un dispositivo sea reconocido, autorizado y responsable, y aún mejor si puede distinguir entre una instancia específica de hardware y un script que podría copiarse en cualquier momento. La liquidación tampoco es tan simple como emitir recompensas: debe cerrar el ciclo de la tarea, desde su inicio hasta su ejecución, pasando por la aceptación y el pago, hasta llegar a la auditoría. Si en algún punto de ese ciclo se depende de promesas verbales o de decisiones centralizadas, el sistema terminará degenerando en algo que solo parece estar basado en la cadena, pero en realidad sigue siendo el humano quien toma las decisiones.
En este marco, ROBO es más bien el combustible para la liquidación y las restricciones, en lugar de un boleto para la narrativa. Al menos debe cumplir dos funciones simultáneas: primero, servir como medio de pago, permitiendo que el valor de las tareas se transfiera entre los nodos de los robots, los verificadores y los emisores de tareas; y segundo, actuar como herramienta de restricción: quien participe debe comprometer algo, quien cometa errores deberá asumir las consecuencias, y las disputas deben regirse por normas claras de liquidación. Hablar solo de pagos fácilmente puede llevar a subsidios para inflar las cifras, mientras que hablar solo de castigos puede convertir el sistema en una máquina muy dura, donde al final nadie querrá trabajar de verdad. No estoy seguro de cómo Fabric logrará encontrar el equilibrio, pero yo vigilaré qué capas convierte en necesidades imperiosas y qué capas solo quedan escritas sobre el papel.
Hablando de verificación, en realidad no me llaman mucho la atención los términos técnicos; lo que más me interesa es saber qué problemas del mundo real realmente resuelve. Por ejemplo, con OM1, prefiero entenderlo como un tiempo de ejecución o una capa intermedia orientada a las tareas de robots. Su valor no radica en lo avanzado que sea, sino en si puede unificar la descripción de las tareas, los registros de ejecución y las interfaces de liquidación bajo un mismo estándar, evitando que diferentes stacks de hardware y software hablen lenguajes distintos. En la vida real, el ecosistema de los robots es muy fragmentado: ROS2, SDKs de fabricantes, protocolos privados se mezclan sin orden ni concierto. El formato en que se registran las tareas, cómo se firman, cómo se devuelven los resultados… todos estos son detalles de ingeniería. Si OM1 logra nivelar esos detalles, entonces las liquidaciones de tareas tendrán la oportunidad de escalar; de lo contrario, cada vez que se integre un nuevo tipo de dispositivo, habrá que volver a configurar todo el pipeline desde cero. Los riesgos también están ahí: una vez que la capa de abstracción se convierte en un estándar de facto, aparecen las dependencias; la compatibilidad, la gobernanza de código abierto y la auditoría de seguridad se vuelven cruciales. Yo me fijo en si los equipos externos pueden replicar y mantener el sistema, en lugar de limitarme a seguir únicamente la versión oficial.
Por ejemplo, con PoRW, prefiero traducirlo como Prueba de Trabajo Real. La clave no está en el nombre, sino en la ruta de verificación: ¿qué pruebas utilizas para demostrar que el trabajo realmente tuvo lugar? Y, además, ¿qué mecanismos garantizan que el costo de la falsificación sea superior a los beneficios? La mayoría de las pruebas en el mundo real provienen de sensores, cámaras, odómetros y contadores eléctricos; estas entradas pueden ser falsificables o bien requieren hardware confiable o validación cruzada entre múltiples partes. La validación cruzada conlleva latencia y costos, mientras que el hardware confiable impone barreras en la cadena de suministro y en la implementación. Cuando Fabric menciona componentes como VPU o computación verificable, mi interpretación es que está intentando convertir la verificación en un servicio reutilizable, modularizando los procesos de comprobación y permitiendo que el sistema pueda equilibrar costos, velocidad y confiabilidad. La dirección es correcta, pero yo estaría atento a dos extremos: si la verificación resulta demasiado cara, los márgenes de ganancia de las tareas se verán absorbidos por los costos de verificación, y al final solo quedará contar historias; y si la verificación es demasiado laxa, los tramposos acabarán usando el sistema como un cajero automático. Las fricciones del mundo real son difíciles de eliminar solo con un libro blanco; solo aparecerán en los datos en forma de costos, latencia y tasas de disputas.
También me importan mucho la responsabilidad y la auditoría. Que un robot haga algo mal no es solo un riesgo abstracto; puede tratarse de chocar contra estanterías, herir a personas por error o manipular equipos de forma inadecuada. Si la liquidación en cadena solo se preocupa por pagar cuando la tarea está completada, en realidad está incentivando resultados a corto plazo, sin preocuparse por el proceso ni por la posibilidad de rastrear las responsabilidades. Yo prefiero una dirección que vincule más estrechamente los registros del proceso con la liquidación, porque solo si los procesos son trazables podremos hablar de asignación de responsabilidades. El problema es que los registros también pueden ser reportados de manera selectiva; especialmente cuando los nodos saben qué campos afectan a los ingresos, tenderán instintivamente a optimizar esos mismos campos. Me fijo en si el sistema cuenta con mecanismos de inspección aleatoria, de desafío y de arbitraje de disputas; si las sanciones por incumplimiento son lo suficientemente severas, y al mismo tiempo si el proceso para resolver las disputas es lo suficientemente fluido, para evitar arrastrar a los operadores honestos a un laberinto interminable de apelaciones.
Si me preguntas cuál es la señal real más importante que debes vigilar, no me fijaré en los eslóganes ni en los precios a corto plazo. Prefiero centrarme en indicadores que son muy difíciles de falsificar mediante estrategias de marketing: ¿está aumentando de forma constante el número de liquidaciones de tareas reales? ¿Provienen las liquidaciones de una variedad de emisores de tareas, en lugar de provenir de unos pocos direcciones que solo repiten transacciones una y otra vez? ¿Se mantiene un intervalo estable en cuanto a la latencia media de las liquidaciones y a la tasa de disputas? ¿Se gestionan eficazmente las disputas en lugar de dejarlas acumularse? ¿Ha ido disminuyendo la proporción de los costos de verificación respecto al valor de las tareas? ¿Es esa disminución fruto de una mejora en la eficiencia o de una relajación en los procedimientos de verificación? ¿Está la distribución de los nodos más descentralizada? ¿Son transparentes las auditorías de seguridad y las respuestas a vulnerabilidades de los módulos clave? Estas cosas no necesariamente pueden derivar directamente en un precio, pero sí responden de manera más directa a la pregunta de si el sistema está funcionando y si lo hace de forma estable.
Mi actitud hacia ROBO es más parecida a la de hacer experimentos que a la de apostar por un resultado final. Si realmente quiere soportar la economía de los robots, tendrá que enfrentarse a las restricciones más básicas: ¿quién paga?, ¿quién demuestra?, ¿quién asume la responsabilidad?, ¿cómo se investiga cuando ocurren problemas? ¿Y después de la investigación, cómo se compensa? Si falta cualquiera de estos eslabones, al final es posible que volvamos al modelo de las plataformas de externalización centralizadas, solo que con una capa adicional de liquidación en cadena. No estoy seguro de hasta qué punto Fabric podrá fortalecer estos eslabones, pero yo lo verificaré de manera más ingenieril: observando los datos en cadena, analizando el manejo de las disputas, examinando la curva de costos y viendo si los emisores de tareas a largo plazo siguen enviando pedidos de forma continua, en lugar de limitarse a aprovechar el período de incentivos para sacar provecho una sola vez. Los proyectos que puedan resistir este tipo de análisis, aunque crezcan un poco más despacio, son los que yo prefiero reconocer como verdaderos constructores.
