La famosa premisa de “Code is Law”, junto con muchos de quienes la aclaman, se cae a pedazos cuando recordamos que la naturaleza humana es tanto torpe como muchas veces maliciosa.

El código es creado por programadores que, al ser humanos, pueden cometer errores. Si algo que TheDAO[1] nos dejó, entre muchas otras cosas, como moraleja, es que esos errores o “bugs” pueden ser muy costosos para los miembros de la comunidad e industria.

Como dijimos, además de torpe, puede ser maliciosa. La pícara utilización de mecanismos de consenso con fines non sanctos y de difícil detección dio origen a varios ataques relámpagos en los últimos años, en que la innovación se cruzó con la no tan evidente inocencia de los fundadores de más de una DAO.

Una Organización Autónoma Descentralizada, o DAO, se caracteriza parcialmente por estar formada por miembros, o token holders, con derechos a voz y/o voto (derechos de gobernanza). Cuando a los miembros se les permite tomar decisiones referidas a distintas áreas de gobernanza, como el Treasury, es que la creatividad se encuentra con la mala fe de aquellos lo suficientemente rápidos. Curiosamente, la game theory de John Nash juega un rol muy importante en estos casos.

Los mecanismos de consenso son un problema computacional que los mineros resuelven para verificar y validar la información que se agrega al sistema distribuido, asegurando que solo se registren transacciones auténticas en la blockchain. Al no depender de una autoridad central que valide las transacciones y la veracidad de las mismas, como a su contenido, son estos mecanismos de consenso los que en la misma blockchain y a través de distintas operaciones computacionales realizan este trabajo.

Para que estos mecanismos corran óptimamente dentro de un protocolo, deben considerarse fundamentalmente tres aspectos. Es aquí donde se genera el trilema de la escalabilidad, denominado por el fundador de Ethereum, Vitalik Buterin, ya que un mecanismo de consenso puede, por el momento y por las limitaciones tecnológicas actuales, limitarse a cumplir solo dos características de la red:

- Seguridad de la Red,

- Escalabilidad en la forma de rendimiento de transacciones, y

- Descentralización (como capacidad de la red para continuar operando a pesar de fallas o ataques)

El desequilibrio entre estas y los cuantiosos riesgos que corren las DAOs explica que ciertos protocolos, inclusive, ofrezcan rewards millonarios para bounty hunters. Otros, en lugar de tomar dicha oferta, prefieren los flash attacks.

Beans: un stable token particular

Promediando el mes de Abril de 2022 ocurrió el más importante ataque relámpago a un protocolo de finanzas descentralizadas (DeFi)[2]. Se trata del caso de mayor envergadura desde el auge de las DeFi, considerando como dies a quo el despegue en 2019 del ecosistema DeFi (aunque podría argumentarse que el ecosistema DeFi nació con el criptoactivo conocido como Dai en 2017).

Los hechos del caso Beanstalk, simplificados, son los siguientes: el protocolo Beanstalk, lanzado en Septiembre de 2021, ofrece tres criptoactivos llamados Beans, Stalks y Seeds, creados todos usando el estándar ERC-20 de tokens fungibles de la red pública no permisionada de Ethereum[3].

Los Beans se ofrecían con un supuesto valor estable 1:1 con el dólar, por lo tanto, se los diseñó específicamente como un criptoactivo con finalidad de pago y mecanismo de estabilidad en su valor[4]. Este criptoactivo “estable” presentaba un diseño distinto a las otras especies preexistentes de stable tokens, al no pedir integrar garantías para su emisión (over-collateralization, como el caso del Dai[5]), lo cual lo convertía en un stable token muy particular.

El protocolo Beanstalk permitía, por un lado, depositar Beans en un contrato inteligente, de modo tal de formar un pool de liquidez, retribuyéndose a los depositantes con nuevos Beans creados algorítmicamente, siempre con el fin de utilizar esta reserva, a la que  denominaron Silo, como un mecanismo de estabilidad del valor “estable” 1:1 de los Beans.

El protocolo, por otro lado, permitía también depositar en el Silo otros criptoactivos distintos de los Beans, como Ether, para generar mayor reserva de valor, entregándose en éste caso también un token de gobernanza, llamado Stalk, el que otorgaba ciertos beneficios pagaderos en Seeds, y además ciertos derechos “políticos” a su tenedor, para proponer y votar para aceptar (o no) modificar (vía upgrades y updates) el protocolo y sus funcionalidades, votando las propuestas respectivas documentadas en BIPs (Beans Improvement Proposals).

Finalmente, el protocolo creó una Decentralized Autonomous Organization (DAO), llamada Beanstalk DAO, para gestionar la creación de los tres tipos de tokens y las tomas de decisiones por parte de los tenedores de tokens Stalks. Por tanto, este protocolo, sus funcionalidades, y sus modificaciones, era gobernado a través de una DAO gestionada por aquéllos que tuvieran los tokens de gobernanza Stalks, es decir, era gestionada por sus miembros a través de un mecanismo de consenso de tipo PoS. El código fuente de esta DAO y de todo el protocolo estaba publicado open source, con lo cual cualquier usuario con  las habilidades necesarias podía analizarlo, y en su caso, decidir participar. O decidir atacarlo explotando algún defecto de codificación, si existe (como en el caso TheDAO), o simplemente aprovechando las nuevas posibilidades tecnológicas, y vaciar el Silo. 

El mayor ataque relámpago (flash attack) a la fecha

En la noche del domingo 17 de Abril de 2022, Beanstalk fue víctima de un ataque relámpago que duró 10 segundos, y terminó vaciando las reservas (el Silo) del protocolo, generando para sus usuarios la pérdida de diversos tokens, por un valor de 180 Millones de dólares, y una ganancia neta  estimada para el atacante de 80 millones de dólares. ¿Se trató de un robo perfecto?¿O de una conducta tecnológicamente legal, pero socialmente disvaliosa?

El atacante (o el usuario infiel) se apalancó, tomando préstamos instantáneos (i.e. flash loans[6]) en otra plataforma DeFi, Aave, casualmente la primera plataforma en ofrecer este tipo de préstamos instantáneos sin garantía. Estos flash loans[7] son préstamos instantáneos, que se otorgan sin garantía de ningún tipo, ya que se devuelven en un muy corto período de tiempo (i.e. segundos, en una transacción contenida dentro del mismo bloque), vencido el cual si el préstamo no se devolvió, toda la transacción se cancela automáticamente. Los flash loans permiten de facto suprimir el riesgo de contraparte, lo que a su turno posibilita tomar estos préstamos en criptoactivos de manera muy fluida y prácticamente sin límites (salvo por la oferta limitada de todo el circulante ofrecido por CEXs y DEXs), generalmente para aprovechar oportunidades de arbitraje[8].

Gracias a los flash loans, el atacante pudo comprar la cantidad suficiente de Stalks que le permitiera aprobar una propuesta. El atacante luego “camufló” su intención verdadera en una propuesta (BIP) que proponía donar parte (200k) de los criptoactivos de la reserva de Beanstalk hacia una dirección oficial de Ucrania, a donde genuinamente se reciben donaciones en criptoactivos. Oculto en el código del BIP 18/19[9], había instrucción que, de aprobarse, transferiría el resto de los  fondos de la reserva hacia una dirección privada de Ethereum. Aprobada que fue la transacción por el mismo atacante en posesión de la cantidad suficiente de Stalks, se vació la reserva de Beanstalk, y los Beans pasaron de valer U$D 1 a 0.11 centavos en pocas horas.

Dado el carácter pseudónimo de las redes públicas no permisionadas como Ethereum, la identidad real de la persona atrás de la maniobra no es conocida, aunque el registro de Ethereum permite seguir los movimientos de los tokens ERC-20 afectados, hasta cierto punto, ya que en el caso, luego de pagados los flash loans pedidos -en segundos-, el atacante pudo lavar los tokens remanentes, valuados en 80 millones de U$D, a través de un servicio de anonimización por mezclado, ofrecido por Tornado Cash[10]. Los fundadores de Beanstalk  están colaborando con el FBI  para intentar trazar y recuperar los tokens robados.

Como se aprecia, el atacante no tuvo siquiera que encontrar un defecto de programación (bug) que le permitiera vaciar los fondos de una DAO (como ocurrió en el célebre caso TheDAO en 2015[11]), sino que utilizó, de una manera maliciosamente creativa, los protocolos en vigor (básicamente el PoS teniendo Stalks, y el sistema de aprobación por super mayoría vía BIPs).

Otros casos usando flash attacks

El caso Beanstalks, si bien es el de mayor volumen involucrado a la fecha, dista de ser un caso aislado. El primer ataque de este tipo tuvo lugar en Febrero de 2020, y afectó al protocolo bZx[12] por manipulación, explotando un bug en un smart contract en una maniobra de cinco pasos que fue la primera de su especie.

Pero solo meses después, en Noviembre de 2020, el protocolo DeFi Origin sufrió el mayor ataque de este tipo a tal fecha[13]. Se trató también de un ataque a un stable token, conocido como OUSD (Origin Dollar), emitido por el protocolo Origin. En este caso sí existió un defecto de programación (conocido como re-entrancy bug, el mismo defecto que permitió el ataque a TheDAO) en el smart contract que creaba los OUSD, que fue detectado y explotado por el atacante, que pudo hacerse de 7.137 ethers y 2.249 M de Dais, que fueron luego enviados a una wallet controlada por el hacker, para luego ser lavados en TornadoCash, wBTC y renBTC. 

En este caso, el atacante tomó un flash loan de 70.000 ethers del DEX conocido como dYdX, los que luego convirtió a Dais y USDT (Tether) en otro DEX, Uniswap. Con estos stable tokens, el atacante generó OUSD en una cantidad levemente mayor a la mitad del total en circulación, y, explotando el defecto de programación, pudo crear más  OUSD que los que le hubieran correspondido, y canjearlos en UniSwap y SushiSwap por USDT (Tether).

También en el mes de Noviembre de 2020, Value Defi, otro protocolo similar sufrió un ataque que generó pérdidas por 6 millones de Dólares en Dais[14], pero en este caso se usaron dos flash loans separados: se pidieron 80,000 ethers de la plataforma Aave y 116 millones de Dai desde UniSwap. El atacante swapeó el préstamo en Ethers por distintos stable coins, que depositó junto con los Dais en la bóveda del protocolo. Luego realizó distintos swaps entre stable tokens, lo que explotó una falla en el smart contract que le permitió escapar con tokens valuados en 6 millones de dólares. Días antes, otras plataformas DeFi habían sido víctimas de ataques usando flash loans, Akropolis[15] y Harvest Finance[16], perdiendo 2 y 2,5 millones de Dólares en criptoactivos, respectivamente.

Medio año después, ya en Mayo de 2021, otro protocolo DeFi, xToken[17], sufrió un ataque con flash loans pero en este caso, las pérdidas ya fueron muy superiores, y alcanzaron los 24,5 millones de Dólares. Este protocolo ofrecía ocho criptoactivos distintos, dos de los cuales fueron atacados. En este caso, usando un flash loan por 61,800 ETH, el atacante detectó un bug en la codificación de un smart contract que le permitió manipular los valores del oráculo que xToken usaba para aceptar el valor de determinados tokens. Nótese que el costo de esta transacción, compleja, fue de 5 Ethers.

También en Mayo de 2021, un ataque con flash loans al protocolo DeFi PancakeBunny, desarrollado en la Binance Smart Chain (BSC), produjo que el token nativo de la plataforma  Bunny,  los Bunny tokens, perdieran 95% de su valor en segundos[18].  En este caso, al atacante tomó prestados una gran cantidad de tokens de Binance, BNB[19], usando PancakeSwap, y con ellos manipuló el precio de cambio entre USDT/BNB y Bunny/BNB en los pools de liquidez de PancakeBunny[20]. Esto le permitió hacerse de una gran cantidad de tokens Bunny recién creados, cancelar el flash loan y escapar con 3 millones de Dólares en criptoactivos, generando pérdidas por casi 50 millones.  Pocos días antes, otro protocolo DeFi nativo de la BSC también sufrió pérdidas por más de 10 millones de Dólares al ser atacado usando flash loans[21].

El gobierno descentralizado y los (nuevos) riesgos propios del ecosistema DeFi

Se ha sostenido que así como el 2017 fue el año de las ICOs, 2020 fue el año de los protocolos DeFi[22], y con éstos, se potenció el uso de oráculos, generalmente centralizados y operados por empresas, para tomar datos externos de precios de cientos de Exchanges (CEXs y DEXs) para introducirlos a un protocolo DeFi (como Aave, Compound, MakerDAO[23]  y UniSwap) montado en redes públicas como Ethereum o BSC.

La manipulación de los oráculos (i.e. el problema de los Oráculos) usando flash loans es quizás el mayor riesgo cibernético de toda el vertical DeFi, a lo que cabe sumar, quizás, el riesgo regulatorio de no poder cumplir con protocolos de KYC-AML-CFT a nivel de los DEX, aunque en éste frente se están dando avances[24].

Por tanto, el diseño de oráculos debe tener especialmente presente el riesgo de manipulación vía flash attacks, dado que éste tipo de ataque, por toda métrica, es (y será) el más común en el ecosistema DeFi. Este riesgo quedó muy manifiesto con uno de los primeros usos tecnológicamente legales de un flash loan para adquirir tokens de gobernanza y tomar una decisión en beneficio propio, pero afectando a un protocolo DeFi, tal fue lo ocurrido en Octubre de 2020 con MakerDAO[25]. En este caso, un grupo de desarrolladores quería conseguir acceso al oráculo que MakerDAO utiliza, y para lograrlo, tomaron un flash loan, compraron una cantidad significativa de tokens MKR, y votaron a favor de su propuesta (conducta de allí en más fue bautizada como flash loan voting). Toda la transacción fue oportunamente comunicada a la comunidad por parte de sus ideólogos, pero ésta decidió tomar medidas para que tales conductas no se repitieran, esencialmente ampliando el período ventana que sigue a una votación, pero que precede a su implementación[26]. 

Evidentemente, si el flash loan voting puede ser considerado un riesgo sistémico en los protocolos DeFi, ello es así debido a que éstos generalmente optan por un sistema de gobierno descentralizado, gestionado por una DAO, y operado a través de tokens de gobernanza (como los tokens MKRs o Stalks), diseñado sobre la base de un mecanismo de consenso del tipo Proof Of Stake (PoS), que otorga ciertos derechos “políticos” a su tenedor (o a su delegado, cuando se emplea un mecanismo de tipo DPoS).

El caso de Steemit,  una red social tokenizada lanzada en 2016 sobre su propia blockchain (Steem), magistralmente analizado por Shermin Voshmgir[27], analiza la problemática del emplear protocolos del tipo DPoS, en los cuales la comunidad vota por designar “testigos o delegados”, a quienes se delegan los votos asociados a los tokens STEEM (y que puede ser removidos).

En Febrero de 2020, la fundación Tron, que gestiona la blockchain Tron, adquirió Steemit, Inc. La comunidad del ecosistema de Steem expresó preocupaciones por la adquisición y el nuevo liderazgo, que, entre otras cosas, propuso un plan para migrar los tokens de STEEM a la red de blockchain de Tron. Otra preocupación de la comunidad, aún mayor, era que con esta adquisición, la fundación de Tron también ganó control de alrededor del 20% del total de los tokens STEEM, a los cuales la comunidad los llamaba coloquialmente “la participación ninja acuñada por Steemit Inc”. A estos tokens ninja se los pre-acuñó hace años y se distribuyeron a los fundadores de STEEM, que ahora vendían Steemit Inc. a la fundación Tron.

Si bien los tokens ninja siempre representaron una amenaza, nunca se los había usado de manera activa (como para votar en actualizaciones de la blockchain Steemit). La comunidad de Steemit estaba segura de que los fundadores de la red no usarían incorrectamente estos tokens para tomar control de la red. Sin embargo, debido a la desconfianza hacia los nuevos dueños y el temor de una potencial toma de control, los testigos (DPoS) de Steem, casi de manera inmediata, ejecutaron una soft fork de la blockchain de Steem con votos que los usuarios de la red les habían delegado.

Con esta acción, se bloquearon los tokens ninja de actividades futuras para tomar control de la red. La comunidad votó por este soft fork para prevenir que los dueños nuevos (la fundación Tron) pudieran usar los token ninja. Los testigos justificaron la acción como un “protocolo temporario de protección para mantener el statu quo establecido actualmente en relación a los intereses de Steemit Inc. y su uso previsto […] y el uso continuo de los activos que controla”. El soft fork liderado por la comunidad falló porque la fundación Tron coordinó con algunos Exchanges para deshacer de manera retroactiva el fork con los tokens STEEM de usuarios alojados en esas plataformas. Se debatió arduamente el uso incorrecto de los tokens de usuarios por parte de los Exchanges.

En lugar de luchar por el poder en la red de Steem, la comunidad decidió separarse, ejecutando una secesión a través de un hard fork. A mediados de Marzo, ocurrió el forkdel protocolo de la blockchain de Steem y de la aplicación de Steemit, hacia una red nueva con el nombre de “Hive”. Se censuró a todos los token ninja controlados por Steemit Inc. y no se los migró a la nueva red de Hive. Todos los otros tokens de red se transfirieron a Hive. También se transfirió toda la información del blog de la aplicación de Steemit a la red de Hive. De allí en más, dependería de cada bloguero decidir cual aplicación utilizar en el futuro, Steemit o Hive.

La adquisición y los posteriores forks demostraron la naturaleza descentralizada de las redes de blockchain, pero también exhibieron vectores de ataque potenciales con mecanismos de consenso de prueba de participación delegada (DPoS, por sus siglas en inglés). Lo que originalmente tenía como objetivo una red social descentralizada, demostró ser propensa a la centralización, por la adquisición de la fundación Tron y por su conspiración con Exchanges que utilizaron los tokens de sus usuarios para realizar votos (sin su previo consentimiento). También demostró el poder de los testigos, que actuaron como cabecillas de estas bifurcaciones[28].

Si bien Steemit sentó las bases para una nueva era de redes sociales, al demostrar cómo podemos replantear las redes sociales en una economía tokenizada, sus defectos de diseño fueron considerables.

Conclusiones

De los casos expuestos podemos observar que todos ellos exponen un patrón común: riesgo sistémico inherente a la dinámica de los ecosistemas creados. Con diversos matices, bien por riesgos en la arquitectura del codigo (problemas que denominaremos como bugs) o bien en la macro-arquitectura funcional del mecanismo de consenso y el decision making process, no menos cierto es que los eventos acontecidos recientemente en particular, pero la historia más próxima de los 3 últimos años en general, deben resultarnos un sensor de alerta para quienes trabajamos con y en estos espacios.

Los mayores desafíos que se nos presentan, en un contexto aún cargado de poca claridad y balcanización regulatoria, se corresponden con la de pensar mecanismos que sin perder el espíritu y las bondades que las DLTs nos ofrecen, evite que su empleabilidad se transforme en una caja de pandora con downsides potenciales no correlacionados con los beneficios esperados.

Podemos encontrar así alternativas para eliminar o mitigar estos riesgos, siempre que asumamos que no tenemos aún un marco regulatorio claro que nos obligue y/o clarifique como hacer esto. Siguiendo este razonamiento podríamos pensar en mecanismos de consenso superadores a los existentes, que por ejemplo, tengan dinámicas blend, explotando así los mejores atributos individualmente considerados de ellos pero de manera sinérgica.

Un ejemplo de esto podría ser una iteración de consenso entre dos protocolos dentro de un mismo ecosistema, tal que uno haga contrapeso del otro y viceversa. De esta manera podríamos pensar mecanismos de consenso tales como PPoS, PoS, DPoS, PoA entre otros integrados en un mismo proceso descentralizado de toma de decisiones.

En línea con esta alternativa propuesta, podemos pensar el concepto de SupraDAOs, donde siendo la DAO un sistema en sí mismo, en un proceso homeostático continuo, podría pensarse en ella como un todo y a la vez parte de otro sistema aún mayor, donde cada uno de los sistemas (DAOs) integrantes cumplan un rol en el voting process and decision making process del ecosistema. Estas alternativas expuestas, podrían ser muy buenos enfoques para mitigar (al menos) el riesgo sistémico propio e inherente al empleo de la tecnología subyacente de estos protocolos. Un caso testigo de este tipo de counterweight lo vemos en Synthetix[29], donde como estrategia para mitigar riesgos de esta naturaleza se propone la creación de un ecosistema de 5 DAOs[30] (SpartanCouncil, grantsDAO[31], the ambassadorDAO, the Treasury Council, y the protocolDAO) con facultades autónomas e independientes cada una de ellas, pero interconectadas, y condicionadas, tal que ningúna individualmente podría alterar per se el ecosistema pero todas ellas son necesarias a la vez para el correcto funcionamiento del mismo (una especie de gobernanza descentralizada y por instituciones) .

Finalmente, pero no menos importante, no hay que perder de vista las validaciones y revisiones de los protocolos, básicamente procesos de auditoría de código realizados por idóneos/expertos, ya que de lo contrario, por muy bien diseñado el mecanismo de consenso y formación de voluntad colectiva, siempre quedamos a merced de bugs o simplemente errores de script que exponen significativamente al ecosistema, la industria y en general a la sociedad que progresivamente comienza a entender los atributos de valor que esta tecnología puede aportar a los problemas de la actualidad.