#bedrock $BR Hace un tiempo me pasó una situación bastante incómoda. Un protocolo DeFi anunció que iba a actualizar el contrato y pidió a los usuarios que migraran manualmente la liquidez. Seguí el tutorial, pero en la parte de autorización hubo un error, y después de quemar una tarifa de gas, la migración falló. Intenté de nuevo, y otra vez falló. Finalmente, pregunté en la comunidad y descubrí que no era un caso aislado, era un problema de compatibilidad por la actualización del contrato. Después de más de media hora de líos, logré solucionarlo, y desde entonces tengo más cuidado con la frase "actualización de protocolo". $ETH
Después revisé la documentación de @Bedrock , y fui a investigar su mecanismo de actualización de contrato.
En la arquitectura de Bedrock 2.0, la lógica de emisión de contratos core como uniBTC y brBTC no se puede cambiar a la ligera. Los derechos de actualización están en manos de un multisig, y además, el multisig no es solo de Bedrock. Cada vez que hay una actualización, se necesita la firma de varias partes independientes para ejecutarla. Aunque este mecanismo no elimina completamente el riesgo de que "el equipo del proyecto haga algo malo", al menos eleva el umbral. Lo que dice una persona no cuenta, necesita el consentimiento de un grupo.
Lo que me llamó más la atención es que Bedrock, en cuanto a actualizaciones, ha hecho que muchos parámetros sean configurables en lugar de reemplazables. ¿Qué significa esto? Algunos protocolos, para cambiar un parámetro de rendimiento, tienen que reemplazar todo el contrato, lo que es arriesgado y complicado. Desde el diseño inicial, Bedrock ya hizo que parámetros comunes como tasas, distribución de incentivos y pesos de pools sean configurables, y se pueden ajustar a través de votación de gobernanza, sin necesidad de tocar el contrato core. Esto garantiza flexibilidad y reduce el riesgo asociado a actualizaciones.
Revisé su historial de auditorías. Los contratos principales de Bedrock han pasado por auditorías cruzadas de varias empresas, incluyendo Slow Mist y CertiK. Las auditorías no pueden garantizar que no haya vulnerabilidades al 100%, pero múltiples rondas de auditoría al menos muestran que el equipo no se ha tomado a la ligera la seguridad. $BTC
Y hay un detalle más. El tiempo de bloqueo para las actualizaciones de contratos de Bedrock. Cualquier actualización no urgente, una vez activada, tendrá un retraso en la efectividad. Esta ventana da tiempo a la comunidad para reaccionar. Si hay controversia en una propuesta de actualización, la comunidad puede detectar problemas y presentar objeciones durante este tiempo. Este diseño no es raro en el ámbito DeFi, pero en realidad, no hay muchos proyectos que lo implementen de manera estricta.
Después revisé la documentación de @Bedrock , y fui a investigar su mecanismo de actualización de contrato.
En la arquitectura de Bedrock 2.0, la lógica de emisión de contratos core como uniBTC y brBTC no se puede cambiar a la ligera. Los derechos de actualización están en manos de un multisig, y además, el multisig no es solo de Bedrock. Cada vez que hay una actualización, se necesita la firma de varias partes independientes para ejecutarla. Aunque este mecanismo no elimina completamente el riesgo de que "el equipo del proyecto haga algo malo", al menos eleva el umbral. Lo que dice una persona no cuenta, necesita el consentimiento de un grupo.
Lo que me llamó más la atención es que Bedrock, en cuanto a actualizaciones, ha hecho que muchos parámetros sean configurables en lugar de reemplazables. ¿Qué significa esto? Algunos protocolos, para cambiar un parámetro de rendimiento, tienen que reemplazar todo el contrato, lo que es arriesgado y complicado. Desde el diseño inicial, Bedrock ya hizo que parámetros comunes como tasas, distribución de incentivos y pesos de pools sean configurables, y se pueden ajustar a través de votación de gobernanza, sin necesidad de tocar el contrato core. Esto garantiza flexibilidad y reduce el riesgo asociado a actualizaciones.
Revisé su historial de auditorías. Los contratos principales de Bedrock han pasado por auditorías cruzadas de varias empresas, incluyendo Slow Mist y CertiK. Las auditorías no pueden garantizar que no haya vulnerabilidades al 100%, pero múltiples rondas de auditoría al menos muestran que el equipo no se ha tomado a la ligera la seguridad. $BTC
Y hay un detalle más. El tiempo de bloqueo para las actualizaciones de contratos de Bedrock. Cualquier actualización no urgente, una vez activada, tendrá un retraso en la efectividad. Esta ventana da tiempo a la comunidad para reaccionar. Si hay controversia en una propuesta de actualización, la comunidad puede detectar problemas y presentar objeciones durante este tiempo. Este diseño no es raro en el ámbito DeFi, pero en realidad, no hay muchos proyectos que lo implementen de manera estricta.