Axie, Ronin y la Gestión del Riesgo Tecnológico

La semana pasada trascendió la noticia de que Axie Infinity, un popular juego de modalidad Play-to-Earn, actualmente evolucionando a Metaverso, experimentó una vulnerabilidad tecnológica que derivó en la pérdida de aproximadamente US$ 625M.

Esta no es la primera vulnerabilidad tecnológica que sucede en relación a proyectos Crypto y DeFi, pero este caso da el pretexto para analizarlo, ver cómo los proyectos gestionan la tecnología, el riesgo tecnológico, cómo implementan planes de continuidad y traducen esto en sus términos y condiciones de uso, o no.

¿Qué es Axie Infinity?

Axie Infinity tiene un modelo de Play-to-Earn, que significa un modelo de juego que permite a los jugadores obtener ganancias en tokens mientras juegan. Estos modelos son muy relevantes actualmente en los ecosistemas de criptoeconomía, ya que conjugan un entretenimiento habitual con la posibilidad de obtener ganancias y transaccionar los ítems del juego. A ellos se suman los usuarios que solamente quieren tener los tokens asociados al juego como inversión y no pretenden jugar.

Este tipo de proyectos han reunido el gaming (como entretenimiento) con crypto y son los principales candidatos a convertirse en Metaversos de entretenimiento. Los P2E han jugado un rol protagónico en la adopción crypto del último tiempo, aunque algunos gamers tradicionales se muestran escépticos. El gran desafío para estos juegos es reunir el modelo de tokenomics con juegos de buen nivel tanto en gráficos como en guiones.

¿Qué sucedió?

Reunir el mundo crypto con el gaming tiene muchos desafíos y uno de ellos es la optimización de las transacciones para que la experiencia de juego no se encuentre obstaculizada por el dinamismo de la infraestructura tecnológica subyacente. Tal como lo ha afirmado Axie:

Con esta finalidad, a inicios de 2020, Axie Infinity decidió implementar el Ronin Bridge, Ronin Network y Katana (Ronin Dex), para facilitar la dinámica del juego. Estas herramientas fueron implementadas por Sky Mavis (otra entidad).

Según la información, Ronin tiene 9 nodos validadores y utiliza PoA (Proof of Authority) como algoritmo de consenso. Este algoritmo es muy eficiente y descansa en la confianza que se tenga a quienes lo ejecutan.

De los 9 nodos validadores, 4 nodos los controlaban los desarrolladores (Sky Mavis), 1 nodo lo tenía la DAO de Axie Infinity y los 4 nodos restantes los controlaban otras entidades, entre ellas: Binance, Ubisoft y Animoca Brands.

El pasado 23 de marzo, la red de Ronin tuvo una vulnerabilidad, originada en que un agente malicioso se hizo con 5 de las 9 claves, por lo que pudo controlar toda la red y esto provocó grandes pérdidas. La vulnerabilidad fue advertida 6 días después, el 29 de marzo y, desde ese momento, se han tomado varias medidas para poder recomponer la situación.

Más allá del caso particular

El ecosistema está siguiendo este caso muy de cerca y se espera que la situación se recomponga, tal como ha sucedido en el pasado con otras, permitiendo que la resiliencia ayude a mejorar el desarrollo de lo proyectos.

La referencia al caso en este artículo solamente sirve de pretexto para tomar y tratar un tema que puede ser subestimado por los proyectos desde el punto de vista jurídico y esto es la relación que existe entre: la infraestructura, quien elige la infraestructura, la gestión del riesgo tecnológico y cómo se plasma en los términos y condiciones de los proyectos.

La elección de la infraestructura y quién la elige

Los proyectos tecnológicos se despliegan sobre determinadas infraestructuras, elegidas por los desarrolladores, pero también, en determinados casos por los usuarios.

Un claro ejemplo de aspectos jurídicos que deben tener los desarrolladores cuando eligen una infraestructura, es el caso de cumplimiento para la protección de datos personales. En este punto, tendrán que ver en qué servidores despliegan el software y las bases de datos que trata este tipo de información; pero también deben considerar aquellos productos y prestadores que más se adecuen a sus necesidades de negocio. Por ejemplo, si se elige un servidor solamente por su ubicación (a fin de cumplir con las transferencias de datos), puede suceder que esos servidores no cuenten con las características técnicas de velocidad, capacidad, mantenimiento etc., que necesita el proyecto.

Sin embargo, hay casos en donde los propios usuarios pueden elegir la infraestructura, por ejemplo, cuando en una compraventa el pago se hace mediante la entrega de BTC, y quienes intervienen son partes en igualdad de condiciones para negociar. Así, ambos pueden acordar usar BTC para esa transacción, y prever los aspectos que les interesan que queden plasmados para dicho caso, por ejemplo, la asunción de riesgos en caso de volatilidad, la conservación o no de la crypto, la libertad para elegir la wallet, evaluación del estado de la red, etc.

Puede afirmarse razonablemente que: en el primer caso, la responsabilidad por la elección de la infraestructura, así como sus riesgos asociados estén completamente a cargo de los desarrolladores tecnológicos y comerciales del proyecto; y, en el extremo opuesto, en la segunda situación, que todo el riesgo se encuentre a cargo de los usuarios.

En el medio de estos dos casos, surge una amplia gama de grises y no está claro cómo se distribuyen los riesgos.

Las blockchain L1 y su escalabilidad

En general, cuando se habla de Blockchain se suelen repetir palabras claves como: descentralización, inmutabilidad, seguridad, etc. Pero lo cierto es que ello no es siempre así.

Si bien blockchain ya se considera una tecnología madura, los adjetivos que en general suelen seguir a este término en papers, conferencias y publicidad, dependen de una gama amplia de variables.

Las blockchains de capa 1 originales, tienen desafíos importantes, entre ellos: la escalabilidad y los costos de transacción. Estos muros son insalvables a la interna de cada red.

Para sortear estos obstáculos importantes para el desarrollo de proyectos de GameFi y DeFi, los líderes han optado por desarrollar ellos mismos, o desplegar sus proyectos usando distintas soluciones de escalabilidad, entre ellas: sidechains y bridges.

Estas soluciones tienen en común que aumentan la eficiencia, en cuanto a cantidad y costos de transacciones, en detrimento de la descentralización, inmutabilidad y seguridad que suele caracterizar las blockchain L1 originales como Bitcoin y Ethereum.

El aumento de la eficiencia repercute directamente en favor de la adopción. Sin embargo, no está claro, como se compensa la pérdida de seguridad al pasarse de la descentralización a la centralización. Especialmente, porque el discurso, fundamentalmente en publicidad, sigue siendo el mismo.

Equilibro entre seguridad y eficiencia en las L1 como Bitcoin y Ethereum

El diseño de las redes de Bitcoin y Ehtereum contemplan un diseño fuerte desde la teoría de juegos, en el sentido, de que establecen incentivos y desincentivos equilibrados para que los actores no actúen de forma desleal, así como también, previniendo que la vulneración tecnológica de uno o varios de ellos no comprometa la red. De todas formas, no están exentas de ser víctimas de la centralización, por eso es importante mantener las redes bajo vigilancia.

Los diseños de este tipo son familiares para los abogados, todos cuando redactamos contratos consideramos este tipo de factores, por ejemplo, si se quiere hacer demasiado gravoso el incumplimiento, se pueden establecer multas altas; o si se otorga la potestad de ejercicio de un derecho unilateral a una parte, se establecen mecanismos más o menos burocráticos para asegurar que su titular lo ejerce de forma adecuada, etc.

La descentralización trae una nueva forma de distribuir riesgos, puesto que los reparte entre los posibles actores y focos de vulnerabilidades: wallet, nodos, bridges, sidechains, exchanges, etc.

En el ecosistema de proyectos crypto se puede observar, con carácter general y sin hacer afirmaciones sobre proyectos concretos, que muchas veces los proyectos toman decisiones de infraestructura tecnológica que modifican la distribución de riesgos inherente a esta, sin equilibrar la balanza adoptando mecanismos adicionales y/o complementarios.

En el caso que comentamos se cambió de una red como Ethereum a una red sumamente centralizada, dejando constancia sí que esa red se iría a descentralizar más adelante. Lo sucedido hizo adelantar dicha gestión y tal como surge de los reportes, se está encaminando (ver actualización del 31/3/2022).

¿La distribución de riesgos en los Términos y Condiciones?

En general, cuando hablamos de blockchain, se dice que el usuario es soberano de sus activos, tokens, ítems, incluso de sus datos personales y de tráfico en internet.

Especialmente en crypto, se hace énfasis en que el usuario es el único responsable de decidir acceder a este mundo y por lo tanto responsable exclusivo de la pérdida de valor del activo en cuestión, así como de todas las vulnerabilidades, errores, etc. Con estos parámetros se redactan todos los términos y condiciones de los proyectos.

Ahora bien, cabe preguntarse, qué tanto debe impactar en la documentación legal el hecho de que la empresa desarrolle el proyecto sobre una infraestructura centralizada de su elección, donde ella misma tiene el control, o la tiene un proveedor tecnológico y el usuario no puede negociar este punto. Incluso en hipótesis de DAOs esta puede ser una decisión restringida para la comunidad.

Por otra parte, esperar a que haya regulación que establezca algo al respecto de forma expresa y con carácter general (no solamente para el mundo financiero) es inverosímil, pero, los proyectos pueden diferenciarse entre sí, agregando valor, mediante una asignación de riesgos de manera equilibrada.

Cuando se sacrifica seguridad para potenciar la eficiencia podría considerarse de orden tomar medidas adicionales y complementarias que compensen la pérdida (tales como instrumentos tradicionales: Contrato de Desarrollo, Service Level Agreement con el proveedor tecnológico y con los nodos que corren PoA, y cualquier formato comercial que corresponda a la naturaleza de la relación).

De esta forma, este caso podría ayudar a aplicar la resiliencia tanto a nivel técnico como a nivel jurídico.

Actualización 6 de abril de 2022

Binance, Animoca Brands, a16z, Dialectic, Paradigm and Accel realizan una ronda de inversión para inyectar 150 M a los efectos de reembolsar los fondos vulnerados en la red de Ronin.

Binance y Animoca figuran como nodos validadores de la red, del resto de las empresas no hay información pública al respecto. Estos nodos no están de los que habrían sido vulnerados, dado que según consta en la información, se vulneraron los 4 nodos en poder de Sky Mavis y un nodo bajo el control de la DAO de Axie Infinity.

Esta actitud por parte de los nodos validadores de la red que ejecutan el algoritmo de consenso PoA consituye un hito y un antecedente en relacion de la forma de actuación de la red ante ciertos eventos.

Según la información disponibe, la parte afectada fue la parte DeFi del juego, puesto que la gente que solamente juega no se vio afectada (según tengo entendido), así como tampoco la gente que optó por seguir usando Metamask y los tokens en Ethereum. El juego siguió e incluso se sacó una nueva versión.

Los más afectados fueron los que usaban los tokens como inversión. Esto es muy interesante, porque el juego es un modelo y la parte financiera otro, en este caso claramente separadas.

En una posible futura regulación DeFi, podría ser razonable requerir planes de continuidad, tal como se exige hoy a entidades financieras. En este caso, el algoritmo era PoA, por lo que la reputación de los nodos validadores es importante. En este caso, si bien la reputación de Sky Mavis se vio comprometida, el resto de los nodos actuaron (al menos dos).

Especulando un poco, entiendo que ese plan de continuidad podría estar atado al algoritmo de consenso que se use.