Últimamente he estado revisando IBC y varias implementaciones de mensajería y puentes, y cuanto más miro, más siento que una transferencia entre cadenas en realidad se trata de contar "¿en quién confío realmente?".


El estado ideal de IBC es que ambos lados tengan clientes ligeros que verifiquen el estado del otro, manteniéndolo bastante limpio; pero muchos puentes rápidamente se convierten en: un grupo de relayers que transportan, más firmas o respaldo de conjuntos de validadores, y quién tiene el control de las actualizaciones.
En cuanto a los permisos, soy muy sensible, si los contratos pueden cambiar la lógica en cualquier momento, si el administrador es una sola llave, eso decide si puedo dormir tranquilo o no.

Recientemente también ha habido mucho ruido sobre el staking y el concepto de seguridad compartida, los rendimientos acumulados parecen atractivos, pero en el contexto de cross-chain, agregar otra capa de "seguridad externalizada" parece simplemente alargar la cadena de confianza...
Luego pensé que era bastante ridículo, yo escribo scripts para ejecutar estrategias con bastante rigor, pero al hacer cross-chain, en realidad me entrego a un montón de componentes invisibles.
De todos modos, mi enfoque actual es muy simple: si puedo usar IBC nativo, no uso puentes complicados; si tengo que usar uno, primero reviso permisos y rutas de actualización, prefiero hacerlo más lento.
Ver original
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
  • Recompensa
  • Comentar
  • Republicar
  • Compartir
Comentar
Añadir un comentario
Añadir un comentario
Sin comentarios
  • Anclado