Hechos clave:
-
El analista Chris Blec muestra cĆ³mo evaluar las caracterĆsticas de seguridad de los proyectos DeFi.
-
Un esquema de cĆ³digo abierto analiza el riesgo de centralizaciĆ³n y financiero de los protocolos.
El ecosistema de las finanzas descentralizadas (DeFi), ahora mucho mĆ”s que nunca, ha sido objeto de estudio y profundo anĆ”lisisĀ tras conocerse el ataque que sufriĆ³ la plataforma bZx y que puso de relieve quĆ© tan descentralizado pueden ser estos sistemas, o cuĆ”nta centralizaciĆ³n aĆŗn tienen muchos de estos proyectos.
En medio de toda esta discusiĆ³n, tambiĆ©n ha surgido quien se ha preocupado por informar a los usuarios sobre cuĆ”nto riesgo corren al utilizar plataformas descentralizadas, y quĆ© es lo que se debe saber o en cuĆ”l de ellas deben depositar su confianza. Es por ello, que en este artĆculo presentaremos dos modelos que permiten determinar cuĆ”nto riesgo corres cuando operas en el sector de las DeFi.
El reconocido analista Chris Blec, en febrero pasado publicĆ³ un documento en el que presentĆ³ una visiĆ³n general de la seguridad operativa que existe en torno a las carteras utilizadas para diversas aplicaciones descentralizadas (dApps).
La seguridad de operaciones (OPSEC) es un proceso que identifica las acciones amigables que podrĆan ser Ćŗtiles para un atacante potencial, si se analizan y se agrupan adecuadamente con otros datos para revelar informaciĆ³n crĆtica o datos confidenciales. La OPSEC utiliza contramedidas para reducir o eliminar la explotaciĆ³n adversaria.
Basado en ese criterio, Blec investigĆ³ los mĆ©todos desplegados por trece proyectos DeFi para mantener los fondos a salvo de los hackers. EvaluĆ³ ocho caracterĆsticas, entre ellas, el bloqueo de tiempo, la seguridad multifirma y otros detalles sobre las claves de administrador.
Uno de las debilidades que Blec hallĆ³ en varios protocolos de los proyectos DeFi que evaluĆ³, es que casi todos poseen llaves privadas que conceden derechos administrativos que permiten realizar cambios y mejoras al contrato inteligente, lo cual pone en riesgo los fondos de los usuarios, en caso de que ese poder cayera en manos malintencionadas.
Este descubrimiento condujo al analista a consultarle a los proyectos, ĀæquĆ© es lo que estĆ”n haciendo para proteger las llaves que otorgan privilegios administrativos?
Partiendo de ello, lo que encontrĆ³ no es muy esperanzador: Ā«lo que he descubierto es que tienes que confiar en el protocolo o el proyecto. Tienes que confiar en lo que dicen. Debes poder confiar plenamente en el equipo central que dice que tus fondos estĆ”n seguros. La razĆ³n de ello, es que no hay manera de que ninguno de estos protocolos te pueda probar que su clave de administraciĆ³n estĆ” 100% seguraĀ».
Blec seƱalĆ³, en un video que acompaƱa al documento, que juntĆ³ cuanta informaciĆ³n pudo de conversaciones, entradas de blog, repositorios GitHub y demĆ”s, para hallar informaciĆ³n sobre la OPSEC en torno a los proyectos que evaluĆ³.
EncontrĆ³ que varios de ellos han protegido su clave de administraciĆ³n aƱadiendo un retraso temporal. Esto significa que cuando alguien hace uso de los privilegios administrativos para realizar una actualizaciĆ³n del contrato inteligente, que es enviada como una transacciĆ³n en Ethereum, entonces esta operaciĆ³n se queda en tiempo de espera, segĆŗn el retraso de tiempo que determina cada protocolo.
Es asĆ como dYdX tiene tres dĆas de retraso; Dharma, en cambio, tiene siete dĆas. Luego estĆ”n otros que no tienen bloqueo de tiempo, lo que significa que no hay retraso, como es el caso de TokenSets y Aave. Sobre ello Chris Blec explicĆ³:
Esto significa que si en Compound, por ejemplo, sucede algo que a la comunidad no le gusta, entonces tendrĆ”n un lapso de dos dĆas para evaluar si las claves privadas han sido comprometidas y determinar si alguien desea ejecutar transacciones maliciosas. Durante estos dos dĆas podrĆ”n invalidar o tomar alguna acciĆ³n que les permita salvar lo que estĆ” comprometido, que esa es la idea detrĆ”s del tiempo de bloqueo.
Otro elemento a estudiar son las llaves multifirmas, que otorgan algunos privilegios administrativos en las plataformas DeFi.
Con estas llaves es posible firmar cualquier transacciĆ³n que se utilice para actualizar el ecosistema. TokenSets, por ejemplo, tiene 2 de 3 de estas multifirmas. Quiere decir que su sistema requiere tres llaves privadas, pero solo dos de ellas deben estar de acuerdo para autorizar cualquier transacciĆ³n que se envĆe para actualizar los contratos inteligentes. Adicional a ello, no posee bloqueo de tiempo, por lo que la actualizaciĆ³n se procesa de manera instantĆ”nea.
Sobre este punto Blec aƱade que no existe manera de que un proyecto pueda probar que todas las claves multifirma estĆ©n en manos de individuos Ćŗnicos.
Ā«Tomo como ejemplo a dYdX, sin que ello signifique que los estoy acusando. Ellos tienen dos de tres claves, pero no hay manera de probar que estas tres claves siempre han sido y siempre estarĆ”n en posesiĆ³n de tres individuos diferentes.
Es posible que un individuo haya creado las tres claves y las distribuyĆ³, pero antes guardĆ³ una copia, lo que dejarĆa las tres llaves en poder de una sola persona. Partiendo de allĆ un montĆ³n de cosas diferentes podrĆan salir mal, asĆ que esto no puede ser visto como una evidencia de buen OPSECĀ», explicĆ³.
Blec ademĆ”s, considerĆ³ la clave de administraciĆ³n reclamada OPSEC, como una caracterĆstica determinante para evaluar los sistemas de seguridad de los protocolos del ecosistema DeFi.
En torno ello encontrĆ³ que la mayorĆa de los proyectos evaluados, no solicitan ninguna informaciĆ³n en contrapartida para suministrar datos sobre cĆ³mo aseguran sus claves privadas. Compound, por ejemplo, utiliza un procedimiento multipartito fuera de lĆnea, implementado por un miembro del equipo central. Por otro lado, Aave, utiliza llaves y un sistema de votaciĆ³n que se mantienen en almacenamiento frĆo.
Ā«No pretendo acusar a nadie de mentir, pero estoy diciendo que tenemos que confiar cada palabra de lo que dicen, en lugar de confiar en un cĆ³digo para estas situaciones. AsĆ que, este renglĆ³n tambiĆ©n nos obliga a confiar en lo que dicen, y esto no puede ser una prueba de su OPSECĀ», aƱadiĆ³.
En la siguiente columna del cuadro elaborado por Blec, compara la clave verificada de administraciĆ³n OPSEC de los 13 protocolos considerados, pero en lo sucesivo llega a la misma conclusiĆ³n: nada es verificable.
Es por ello que el analista aconseja que cada usuario adelante su propia investigaciĆ³n. Puede utilizar los criterios considerados por Blec para determinar cuĆ”les son sus protocolos favoritos y en cuĆ”les depositarĆ” su confianza para depositar sus fondos e invertir.
En este sentido, el analista considera determinante que se evalĆŗe cuĆ”l es el riesgo que se corre y cuĆ”les son las medidas que cada protocolo estĆ” considerando, para evitar los ataques o la explotaciĆ³n de vulnerabilidades. Un dato relevante que aporta, es que los protocolos que ofrecen menos informaciĆ³n, son los que representan mayor riesgo para los usuarios.
Cuando decidas confiar en un proyecto DeFi, pregĆŗntate si realmente confĆas en estas personas, pregĆŗntate si crees que la frase clave semilla no estarĆ” colocada sobre su mesa de cafĆ©, o pregĆŗntate si estĆ”s completamente seguro que el primo de los fundadores no sabe la combinaciĆ³n de la caja fuerte de su casa dĆ³nde se almacena la frase semilla.
Para observar con mayor detenimiento este cuadro puedes acceder aquĆ.
Mide tu exposiciĆ³n al riesgo
Tomando en cuenta que los riesgos no siempre estĆ”n claramente visibles y, a menudo, son difĆciles de interpretar para el usuario promedio, existe una manera de medirlo, utilizando DeFi Score. Se trata de un estĆ”ndar impulsado por la comunidad para evaluar el riesgo de operar en plataformas de prĆ©stamo descentralizadas.
El modelo se basa en un puntaje que permite medir el riesgo de operar en cada proyecto, basado en varios factores que influyen, como por ejemplo, riesgo de contrato inteligente, de centralizaciĆ³n y riesgo financiero.
El modelo califica cada una de estas caracterĆsticas utilizando una puntuaciĆ³n que va de 0 a 10. El esquema, representa una alternativa Ćŗtil para evaluar los riesgos, de un vistazo, y sin la necesidad de conocimientos tĆ©cnicos. Aunque inicialmente fue lanzado por ConsenSys, DeFi Score ahora es de cĆ³digo abierto.
Para obtener mĆ”s informaciĆ³n sobre el proyecto, consulta el GitHub oficial que tambiĆ©n contiene un enlace al documento tĆ©cnico completo.
Los tipos de activos mĆ”s populares (DAI, USDC, WBTC y otros) se clasifican en relaciĆ³n a las plataformas en las que se utilizan. Un puntaje de 10 es lo mejor, es equivalente a indicar que un activo no tiene riesgo. Por otro lado, una puntuaciĆ³n de 0 indica un grado significativo de riesgo y, en consecuencia, que el activo (o plataforma) debe evitarse a toda costa.
En lo que concierne al riesgo de contrato inteligente, el anĆ”lisis estĆ” basado en determinar la seguridad del cĆ³digo subyacente de una plataforma de prĆ©stamos. Este puntaje permite precisar cuĆ”n probado es un protocolo, asĆ como quĆ© tipo de sistemas existen para eliminar continuamente fallas en el cĆ³digo de contrato inteligente. En tĆ©rminos mĆ”s concretos, esto tiene en cuenta la auditorĆa de contratos inteligentes, los programas de recompensas de errores y la verificaciĆ³n formal.
La otra caracterĆstica que evalĆŗa este esquema es el riesgo financiero. AquĆ se trata de cĆ³mo funcionan los mecanismos detrĆ”s de los instrumentos financieros de una plataforma. Esto tiene en cuenta las variaciones en Ć”reas como la liquidez, la volatilidad de los instrumentos y los requisitos de garantĆa.
El riesgo colateral, por ejemplo, se evalĆŗa examinando dos datos, ambos derivados de los datos de la cadena. El primer punto es la media mĆ³vil exponencial (EMA) de 30 dĆas de la relaciĆ³n de colateralizaciĆ³n. El segundo punto es un anĆ”lisis de la cartera de garantĆas mediante el modelo CVaR (Valor Condicional en Riesgo), tambiĆ©n conocido como modelo de dĆ©ficit esperado, segĆŗn se especifica en su pĆ”gina web.
En lo que respecta a la centralizaciĆ³n, el modelo evalĆŗa el riesgo basĆ”ndose en el uso de las claves de administraciĆ³n y los orĆ”culos, enfocĆ”ndose en determinar en quĆ© medida una sola entidad puede manipularlos con facilidad.
Tal como estĆ” a la fecha, DeFi Score incorpora siete plataformas de prĆ©stamos diferentes: Compound Finance, dYdX, Fulcrum (bZx), Nuo (Nuo Network), DDEX, Aave y Oasis. Estas figuran junto a diecisĆ©is criptomonedas populares usadas en DeFi: DAI, USDC, ETH, WBTC, REP, ZRX, BAT y otros. En este momento, Compound tiene la calificaciĆ³n mĆ”s alta, mientras que Oasis figura como la de mayor riesgo.
Una de las razones por las cuales Compound aparece con la puntuaciĆ³n en primer lugar, es por la auditorĆa formal realizada por Open Zeppelin, que sirve como representaciĆ³n de esfuerzo en la mitigaciĆ³n del riesgo del contrato inteligente (la mayor influencia en el puntaje).
A pesar de ello,Ā esta auditorĆa encontrĆ³, en agosto pasado, que aunque se maneja un sistema de seguridad adecuado, el plan de incentivos y los roles privilegiados que se utilizan podrĆa resultar contraproducentes. Asimismo, hay personas que advierten que los usuarios desconocen los posibles riesgos financieros que implica ser prestamista en esta plataforma.
