Wanchain .- La cuestión de la seguridad de los puentes BTC envueltos ha sido una preocupación latente en toda la comunidad DeFi durante mucho tiempo. 

El propio fundador de Ethereum, Vitalik Buterin, destacó el problema en un tweet reciente:

Los comentarios en su publicación estuvieron llenos de un acalorado debate de miembros que representan todos los rincones de Crypto Twitter. 

Se mencionaron varias soluciones de puente convencionales existentes, como las de Republic Protocol (REN) y Wanchain (WAN).

De mi investigación sobre la tecnología segura de cadenas cruzadas como parte de mi trabajo en Wanchain, tengo un buen conocimiento general de varios mecanismos BTC de cadenas cruzadas. Echemos un vistazo a cómo funcionan exactamente y por qué las personas los usan:

El como…

La comprensión más simple y directa de los puentes entre cadenas de BTC es que un usuario transfiere BTC «reales» a una dirección en la cadena de bloques de Bitcoin donde está bloqueado. 

Después de esta dirección recibe el “verdadero” BTC, lo hará de menta un “falso” ERC20 BTC en Etereum. 

Este tipo de token se conoce como token de mapeo o token «envuelto», y se puede usar libremente como una representación de BTC en Ethereum. Al ir en la otra dirección, el ERC20 BTC se quema (destruye) y se libera el BTC bloqueado en Bitcoin. 

Los tokens BTC basados ​​en ERC20 acuñados en Ethereum tienen el prefijo de un símbolo para indicar el protocolo u organización detrás del puente entre cadenas. Por ejemplo, wanBTC, renBTC, sBTC, WBTC, tBTC, etc.

El proceso general para mover BTC desde su propia cadena de bloques nativa de Bitcoin y viceversa se describe mediante este sencillo proceso de 2 pasos.

El porque…

En esencia, al acuñar BTC envuelto, el BTC «real» se intercambia por BTC «falso». Algunos podrían preguntar, ¿por qué querría usar BTC «falso»?

Todo se reduce a los requisitos técnicos. La industria de DeFi ahora está en auge con miles de millones de dólares que fluyen hacia préstamos, opciones y otros tipos de aplicaciones de DeFi. 

La tasa de su aumento exponencial es cada vez más rápida cada día. Sin embargo, este crecimiento se produce principalmente en la cadena de bloques Ethereum. 

Las aplicaciones DeFi en Ethereum solo pueden admitir tokens ERC20, por lo que BTC debe convertirse a la versión ERC20 «falsa» para poder usarlo para prestar, pedir prestado, comerciar, etc. en todas las plataformas DeFi más recientes y más publicitadas que existen. 

Es un caso de uso legítimo. Sin embargo, al empaquetar BTC u otros activos que no sean de Ethereum para que existan en la cadena de bloques de Ethereum, se debe tener especial cuidado con el mecanismo utilizado para empaquetar esos activos.

¿Qué puede salir mal?

Ahora que entendemos cómo funciona el BTC envuelto y por qué la gente lo usa, echemos un vistazo a los peligros potenciales asociados con este proceso. 

El peligro fundamental con todos los BTC envueltos es la posibilidad de que el BTC «real» en la cadena de bloques de Bitcoin pueda desbloquearse y liberarse a otra persona, y dejar a los poseedores de tokens del ERC20 BTC «falso» sosteniendo la bolsa. 

Con el BTC «real» que se suponía que se usaría para canjear, el BTC ERC20 «falso» ahora no tiene valor. 

La forma en que podría suceder este robo depende totalmente del mecanismo específico utilizado para el puente de cadena cruzada que se utiliza para llevar BTC a Ethereum o cualquier otra cadena de bloques que tenga aplicaciones DeFi como Cosmos o Polkadot.

Tipos de Cross-chain Bridge (puentes de cadena cruzada)

Centralized Custodial Bridge (Puente de custodia centralizado)

Con un puente de custodia, la dirección a la que se envía BTC en Bitcoin es simplemente la dirección de una organización que promete que acuñará ERC20 BTC para usted en Ethereum. 

En esta solución, se debe confiar en la persona u organización que administra el puente para que mantenga el BTC real y no se escape con él. 

El ejemplo más destacado de este modelo es el ERC20 WBTC ampliamente utilizado , que está respaldado única y totalmente por la garantía de BitGo .

Decentralized Smart Contract Managed Bridge (Puente gestionado por contrato inteligente descentralizado)

Por supuesto, en el mundo de blockchain y DeFi, muchos prefieren soluciones descentralizadas y sin custodia. Las soluciones descentralizadas se prefieren y se consideran «más seguras», ya que niegan la necesidad de un tercero de confianza (como es el caso de BitGo en el modelo WBTC), y más bien se gestionan directamente mediante una lógica de contrato inteligente inmutable.

Algunas de las tecnologías clave que impulsan estas soluciones son la computación multipartita segura (MPC) y la tecnología relacionada de Threshold Signature Schemes (TSS) .

MPC es una técnica criptográfica que permite que varios participantes realicen operaciones en una serie de entradas sin que ningún participante revele su propia entrada al grupo.

TSS es una técnica criptográfica relacionada que permite que el proceso MPC se complete siempre que un cierto umbral de participantes se unan al proceso. Por ejemplo, con 21 participantes de MPC y un umbral de TSS de 15, siempre que 15 o más de los participantes se unan al proceso, los cálculos se realizarán con éxito.

Consulte este artículo de Noah Maizels de Wanchain para profundizar en MPC y TSS con ejemplos ilustrativos (específicamente la variante de TSS conocida como Shamir’s Secret Sharing).

MPC y TSS aplicados a puentes entre cadenas

Muchas de las implementaciones de MPC / TSS utilizadas por proyectos / protocolos de cadena cruzada se derivan del artículo clásico Robust Threshold DSS Signaturesde Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk y Tal Rabin publicado en 1996.

Desafortunadamente, los principios descritos en este documento a menudo se utilizan directamente en proyectos de cadena cruzada sin modificación o innovación en sus implementaciones de MPC / TSS.

Wanchain introdujo su implementación de MPC / TSS en su primer puente de cadena cruzada entre BTC y Wanchain en 2017. Nuestra implementación se basó en gran medida en el documento de Gennaro de 1996, al tiempo que introdujo un algoritmo innovador que reduce el número de interacciones. en el proceso de cálculo de MPC.

Un concepto importante en la aplicación de la tecnología MPC a los puentes entre cadenas es la relación entre la clave privada individual de cada nodo MPC participante y la clave privada de grupo de todo el conjunto de nodos.

La clave privada del grupo es la clave que se utiliza para controlar la cuenta bloqueada administrada por MPC donde se mantiene el BTC en la cadena de bloques nativa de Bitcoin. Cualquier titular de esta clave tiene control total sobre todos los activos de esa cuenta.

Sin embargo, ningún individuo está destinado a tener esta clave. Más bien, un grupo de nodos trabaja en conjunto para generar la clave privada de grupo a través del mecanismo MPC descrito por Gennaro en 1996.

Esta clave privada de grupo se genera cuando cada nodo MPC participante aporta su propia clave privada individual . 

TSS se aplica a través de este proceso para garantizar que incluso si algunos nodos están fuera de línea o eligen deliberadamente no participar, el proceso se completará siempre que participen más de un número de nodos de umbral. 

Por lo tanto, todo el mecanismo es altamente tolerante a fallas e incluso si los nodos MPC individuales son maliciosos, no afectará la operación del protocolo.

Reagrupación

Si bien MPC permite que un grupo de nodos opere una cuenta BTC bloqueada sin que ningún nodo individual tenga la clave privada, todavía existe la posibilidad de que el número umbral de participantes de MPC pueda coludirse para trabajar juntos para robar el BTC bloqueado.

La reagrupación de nodos, o «batido», es una táctica común utilizada para reducir la posibilidad de colusión de nodos. 

La reagrupación es una técnica en la que los nodos que componen el grupo MPC que gestiona la cuenta bloqueada se barajan periódicamente, de modo que ningún mismo grupo de nodos gestiona la cuenta bloqueada durante un largo período de tiempo. 

Esta mezcla hace que sea mucho más difícil para los participantes identificarse y coludirse entre sí.

Por supuesto, ya que la clave privada grupo se deriva de una combinación de claves privadas individuales todo del nodo participante, cada vez que un nuevo grupo se forma, una nueva clave privada del grupo y asociadas bloqueado cuenta están necesariamente generada por el diseño del protocolo.

MPC y TSS en el puente entre cadenas de renBTC

Echemos un vistazo a cómo el renBTC, cada vez más popular, utiliza MPC y TSS en su puente entre cadenas. Según su informe técnico, su enfoque también se basa en el documento de firmas DSS de umbral robusto antes mencionado .

En su sitio web y documentación oficial , enfatizan que la gestión de las cuentas BTC entre cadenas la realiza un grupo de «nodos oscuros» que utilizan MPC y TSS (específicamente, Shamir’s Secret Sharing), y los miembros de este grupo de «nodos oscuros» ”Se reagrupan periódicamente.

Paradójicamente, descubrimos que la dirección de Bitcoin proporcionada por renBTC a la que los usuarios transfieren su BTC real para bloquear no ha cambiado desde el primer día que se conectó.

El proceso para generar renBTC es el siguiente. Primero, el usuario transfiere BTC a una dirección única. Consulte la Figura 1 a continuación.

Luego, desde esa dirección única, el usuario envía su BTC a la cuenta bloqueada. Consulte la Figura 2 a continuación.

Sin embargo, esa cuenta bloqueada nunca ha cambiado. Como puede ver en la figura a continuación, es un bote de miel de casi 9,000 BTC.

De acuerdo con la lógica de Gennaro, si la dirección de la cuenta es realmente generada por MPC, y los nodos oscuros involucrados en la administración de la cuenta realmente se mueven, entonces la dirección de la cuenta también debe actualizarse periódicamente. Así es como funciona MPC.

Por lo tanto, existe una contradicción entre los hechos observados de la implementación del puente renBTC y la tecnología descrita en la documentación. Esta diferencia parece indicar que el puente renBTC, de hecho, no utiliza el modelo descrito en el documento técnico.

Por tanto, dudamos de que la dirección BTC bloqueada se haya generado de hecho utilizando MPC. Después de una revisión del código en GitHub y varios documentos técnicos, no pudimos encontrar una explicación para esta aparente contradicción.

Más preguntas sobre la implementación de cadenas cruzadas

Presentamos estas preocupaciones sobre la implementación de renBTC porque ahora hay casi $ 100 millones de BTC en lo que podría ser un casillero de almacenamiento centralizado. Sin embargo, los problemas con REN no terminan ahí. El esquema de firma de umbral ECDSA adoptado por renBTC no establece un umbral lo suficientemente seguro para su esquema TSS.

Su esquema de TSS se define así:

n = 3 t + 1

n es el número total de participantes

t es el número umbral de nodos que pueden ser maliciosos antes de comprometer la seguridad del esquema

Por ejemplo, si el umbral t se establece en 15:

n = 3 (15) + 1
n = 46

En otras palabras, bajo este esquema, solo alrededor de un tercio de los participantes (15 de 46) son necesarios para conspirar para comportarse maliciosamente y robar el BTC bloqueado bajo la administración del grupo.

Un umbral tan bajo es peligroso. El mecanismo de consenso Byzantine Fault Tolerant (BFT) ha sido criticado de manera similar dentro de la industria, ya que su seguridad también falla con un tercer o más participantes maliciosos.

Por lo tanto, el esquema TSS de renBTC plantea algunos riesgos de seguridad preocupantes.

Finalmente, tenemos una preocupación más que plantear sobre el proceso de cadena cruzada utilizado para generar renBTC. 

Según la introducción del informe técnico de REN, durante el establecimiento de su cuenta BTC, los «nodos oscuros» completan la interacción de datos a través de una cadena privada, y los datos de interacción están encriptados y su validez está determinada por una garantía de prueba de conocimiento cero . 

Por lo tanto, si la clave privada individual final es correcta depende completamente de esta prueba de conocimiento cero.

Entonces, ¿cómo construir esta prueba de conocimiento cero?

El documento técnico de REN no proporciona un método de implementación específico, ni proporciona referencias relevantes, y no hay implementación de código relevante en su GitHub. Si bien su descripción está repleta de términos criptográficos, de hecho carece de los detalles específicos que permitirían juzgar la seguridad de la prueba de conocimiento cero mencionada:

Como he dicho anteriormente, nuestro equipo de investigación tiene motivos de preocupación con respecto a la ejecución de casi todo lo que se describe anteriormente.

Algunas reflexiones finales …

Este año, especialmente en los últimos meses, el fenómeno DeFi se ha convertido en un movimiento masivo. Los tipos de aplicaciones y el valor total encerrados en los protocolos DeFi han crecido exponencialmente.

Aunque algunos pueden gritar «burbuja», las valoraciones que hacen lagrimear están siendo impulsadas por productos verdaderamente innovadores, y no solo por promesas vacías. 

Sin embargo, a medida que las aplicaciones comerciales DeFi prosperan, las tecnologías centrales de blockchain, como la tecnología de cadena cruzada segura y descentralizada, han seguido el ritmo. 

El propósito de este artículo no es destacar a REN en particular, sino más bien iniciar una discusión racional sobre cuestiones de seguridad dentro del mundo de DeFi entre cadenas.

Primero, ¿qué nivel de compromiso entre los productos descritos en un documento técnico y la implementación real es aceptable?

En segundo lugar, para proyectos como Ren que aún no han revelado su código fuente, ¿qué nivel de detalle debemos exigir en su documentación? ¿Son aceptables las referencias generales a los enfoques de ingeniería o deberíamos exigir detalles de implementación específicos?

En el primer boom de las ICO, vimos demasiados proyectos que se elevaron a valoraciones increíblemente altas basadas solo en un libro blanco y una historia ingeniosa. Toda la industria, incluidos cada uno de nosotros individualmente, fue más o menos una víctima.

Con esa experiencia colectiva en retrospectiva, asegurémonos de no cometer los mismos errores dos veces. Reduzcamos el galimatías técnico, la exageración y los movimientos de manos, y centrémonos en construir soluciones prácticas basadas en sólidos principios teóricos.

El wanBTC descentralizado y sin confianza de Wanchain está programado para lanzarse en Ethereum en el tercer / cuarto trimestre de este año, y agradecemos la evaluación de la comunidad al respecto. Esperamos presentar pronto más detalles sobre su implementación.

«Puedes engañar a todas las personas algunas veces y a algunas personas todo el tiempo, pero no puedes engañar a todas las personas todo el tiempo». – Abraham Lincoln

Autores:

Con contribuciones de:

Guo Wu, Noah Maizels y Nicholas Krapels

Obras citadas:

[1] Rosario Gennaro and Steven Goldfeder. “Fast Multiparty Threshold ECDSA with Fast Trustless Setup”. English. In: ACM, 2018, pp. 1179–1194. isbn: 9781450356930;1450356931;

[2] Rosario Gennaro, Steven Goldfeder, and Arvind Narayanan. “ThresholdOptimal DSA/ECDSA Signatures and an Application to Bitcoin Wallet Security”. In: Applied Cryptography and Network Security. Ed. by Mark Manulis, Ahmad-Reza Sadeghi, and Steve Schneider. Cham: Springer International Publishing, 2016, pp. 156–174. isbn: 978–3–319–39555–5.

[3] Rosario Gennaro et al. “Robust Threshold DSS Signatures”. In: Advances in Cryptology — EUROCRYPT ’96. Ed. by Ueli Maurer. Berlin, Heidelberg: Springer Berlin Heidelberg, 1996, pp. 354–371. isbn: 978–3–540–68339–1.

[4] Philip MacKenzie and Michael K. Reiter. “Two-party generation of DSA signatures”. In: International Journal of Information Security 2.3 (Aug. 2004), pp. 218–239. doi: 10.1007/s10207- 004- 0041- 0. url: https://doi.org/10.1007/s10207–004–0041–0.

[5] Ivan Damg˚ard et al. “Implementing AES via an Actively/Covertly Secure Dishonest-Majority MPC Protocol”. In: Security and Cryptography for Networks. Ed. by Ivan Visconti and Roberto De Prisco. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, pp. 241–263. isbn: 978–3–642–32928–9.

[6] Ran Canetti. “Security and Composition of Multiparty Cryptographic Protocols”. In: Journal of Cryptology 13.1 (Jan. 2000), pp. 143–202. doi: 10.1007/s001459910006.

[7] Torben P. Pedersen. “Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing”. In: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology. CRYPTO ’91. Berlin, Heidelberg: Springer-Verlag, 1991, pp. 129–140. isbn: 3540551883.

[8] Rosario Gennaro et al. “Secure Distributed Key Generation for DiscreteLog Based Cryptosystems”. English. In: Journal of Cryptology 20.1 (2007), pp. 51–83.

[9] Adi Shamir. “How to Share a Secret”. In: Commun. ACM 22.11 (Nov. 1979), pp. 612–613. issn: 0001–0782. doi: 10.1145/359168.359176. url: https://doi.org/10.1145/359168.359176.

[10] Gilad Asharov et al. “A Full Proof of the BGW Protocol for Perfectly Secure Multiparty Computation”. English. In: Journal of Cryptology 30.1 (2017), pp. 58–151.

[11] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. “The Knowledge Complexity of Interactive Proof Systems”. English. In: SIAM Journal on Computing 18.1 (1989), pp. 186–208.

[12] Silvio Micali and Phillip Rogaway. “Secure Computation”. In: Advances in Cryptology — CRYPTO ’91. Ed. by Joan Feigenbaum. Berlin, Heidelberg: Springer Berlin Heidelberg, 1992, pp. 392–404. isbn: 978–3–540–46766–3.35

[13] Donald Beaver. “Foundations of Secure Interactive Computing”. In: Advances in Cryptology — CRYPTO ’91. Ed. by Joan Feigenbaum. Berlin, Heidelberg: Springer Berlin Heidelberg, 1992, pp. 377–391. isbn: 978–3–540–46766–3.

[14] Jens Groth. “On the Size of Pairing-Based Non-interactive Arguments”. In: May 2016, pp. 305–326. isbn: 978–3–662–49895–8. doi: 10.1007/978–3–662–49896–5_11.

[15] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on BFT consensus. 2018. arXiv: 1807.04938v3 [cs.DC].

[16] P. Feldman. “A practical scheme for non-interactive verifiable secret sharing”. In: 28th Annual Symposium on Foundations of Computer Science (sfcs 1987). Oct. 1987, pp. 427–438. doi: 10.1109/SFCS.1987.4.

[17] Lloyd R. Welch and Elwyn R. Berlekamp. Error Correction for Algebraic Block Codes. U.S. Patent 4,633,470. Dec. 1986.

[18] Shuhong Gao. “A New Algorithm for Decoding Reed-Solomon Codes”. In: Communications, Information and Network Security. Ed. by Vijay K. Bhargava et al. Boston, MA: Springer US, 2003, pp. 55–68. isbn: 978–1–4757–3789–9. doi: 10.1007/978–1–4757–3789–9_5.

[19] R. McEliece and D. Sarwate. On sharing secrets and Reed-Solomon codes. English. 1981.

[20] Manuel Cerecedo, Tsutomu Matsumoto, and Hideki Imai. “Efficient and secure multiparty generation of digital signatures based on discrete logarithms”. In: IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences 76 (Apr. 1993).

[21] Michael Ben-Or, Shafi Goldwasser, and Avi Wigderson. “Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation”. In: Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing. STOC ’88. Chicago, Illinois, USA: Association for Computing Machinery, 1988, pp. 1–10. isbn: 0897912640. doi: 10.1145/62212.62213. url: https://doi.org/10.1145/62212.62213.

[22] Donald Beaver. “Efficient Multiparty Protocols Using Circuit Randomization”. In: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology. CRYPTO ’91. Berlin, Heidelberg: Springer-Verlag, 1991, pp. 420–432. isbn: 3540551883.

[23] J. Bar-Ilan and D. Beaver. “Non-cryptographic fault-tolerant computing in constant number of rounds of interaction”. English. In: ACM, 1989, pp. 201–209. isbn: 0897913264;9780897913263;

Reference Code:

https://github.com/renproject/darknode-sol

Ren Token: https://etherscan.io/token/0xeb4c2781e4eba804ce9a9803c67d0893436bb27d

Ren Bridge: https://etherscan.io/address/0x32666b64e9fd0f44916e1378efb2cfa3b3b96e80

Darknodes Fee renBTC: https://etherscan.io/address/0xe33417797d6b8aec9171d0d6516e88002fbe23e7

Darknode Registry Proxy: https://etherscan.io/address/0x2d7b6c95afeffa50c068d50f89c5c0014e054f0a

Mas informacion sobre Wanchain