Foto de Justin Veenema en Unsplash
¡Hola, gente increíble del mundo web! 👋
Prepárense porque en este artículo, ¡daremos un paseo por el camino de los contratos inteligentes Timelock! Vamos a pelar las capas:
- Contratos Timelock: ¿Qué son exactamente?
- El motivo detrás de su existencia.
- Una visión equilibrada de sus pros y contras.
- Y, por supuesto, cómo el protocolo Compound pone en funcionamiento los Timelocks.
Contratos Timelock en Español Simple
Los contratos inteligentes Timelock introducen un mecanismo para retrasar la ejecución de funciones.
Estos contratos emplean modificadores que cambian el funcionamiento de las funciones, asegurando que permanezcan inactivas hasta que haya transcurrido un período predefinido.
Ejemplo de modificador:
modifier onlyBefore(uint time) {
if (block.timestamp >= time) revert TooLate(time);
_;
}
La Motivacion
En el mundo de las blockchains, la gobernanza on-chain es el método preferido para realizar cambios en contratos inteligentes. Sin embargo, hay un problema: puede ser un poco arriesgado.
Imagina un atacante que surge con un préstamo relámpago(flash loan) y hace una propuesta astuta, o un fundador que actúa por su cuenta y realiza cambios sin consultar a nadie. Para evitar estos problemas, proyectos como Uniswap y Compound emplean Timelocks.⏰
Así es cómo funciona: cuando hay una propuesta para ajustar la configuración del protocolo, debe pasar por el Timelock. Este Timelock establece un período de espera definido (normalmente dos días) para la ejecución de la propuesta.
Eso otorga tiempo a la comunidad para reaccionar; pueden cancelar la propuesta o salir del sistema si es necesario. Los Timelocks son como una red de seguridad para la gobernanza on-chain. ⛓️
Pero no termina ahí. Imagina que tienes una plataforma de préstamos que utiliza un oráculo de precios on-chain para calcular cuánto pueden pedir prestado los usuarios.
Un atacante podría manipular ese oráculo para inflar el valor de los activos usados como garantía. Para evitarlo, podrías imponer un pequeño retraso (como un bloque) entre los depósitos y los préstamos.
Este retraso dificulta que el atacante lleve a cabo sus artimañas, manteniendo tu sistema seguro y sólido.🤌
Desventajas de los Timelocks
Atrasos Cortos: los Timelocks son efectivos sólo si el período de retraso es adecuado. Un retraso demasiado corto puede permitir que propuestas maliciosas pasen desapercibidas, como sucedió con el retraso de un día en Beanstalk.
Control Privilegiado: la entidad que implementa el Timelock puede mantener el control. Esto puede llevar a abusos, con alguien modificando el retraso en su propio beneficio.
Dependencia de Timestamp: depender de marcas temporales de bloques para la ejecución puede ser problemático. Los productores de bloques pueden manipular las marcas temporales.
Análisis de Código
Vamos a echar un vistazo más de cerca al código del Timelock del protocolo Compound. Puedes acceder al código siguiendo este enlace: aquí.
Nuestros objetivos principales con este contrato son:
Gestionar Transacciones: comprender cómo se encolan, ejecutan y cancelan las transacciones.
Ajustar el Retraso: aprender cómo actualizar el periodo de espera para la ejecución de transacciones.
Cambiar el Administrador: ver cómo cambia el control del contrato.
Código:
contract Timelock {
using SafeMath for uint;
event NewAdmin(address indexed newAdmin);
event NewPendingAdmin(address indexed newPendingAdmin);
event NewDelay(uint indexed newDelay);
event CancelTransaction(bytes32 indexed txHash, address indexed target, uint value, string signature, bytes data, uint eta);
event ExecuteTransaction(bytes32 indexed txHash, address indexed target, uint value, string signature, bytes data, uint eta);
event QueueTransaction(bytes32 indexed txHash, address indexed target, uint value, string signature, bytes data, uint eta);
}
Implementamos SafeMath en nuestro código para asegurar operaciones aritméticas seguras, y tenemos eventos listados para los contratos inteligentes.
uint public constant GRACE_PERIOD = 14 days;
uint public constant MINIMUM_DELAY = 2 days;
uint public constant MAXIMUM_DELAY = 30 days;
address public admin;
address public pendingAdmin;
uint public delay;
mapping (bytes32 => bool) public queuedTransactions;
Este código define constantes para los periodos de espera, los retrasos mínimos y máximos, establece las direcciones del administrador y del administrador pendiente, almacena el retraso actual y mantiene un mapeo para rastrear las transacciones encoladas por su hash.
constructor(address admin_, uint delay_) public {
require(delay_ >= MINIMUM_DELAY, "Timelock::constructor: Delay must exceed minimum delay.");
require(delay_ <= MAXIMUM_DELAY, "Timelock::setDelay: Delay must not exceed maximum delay.");
admin = admin_;
delay = delay_;
}
fallback() external payable { }
function setDelay(uint delay_) public {
require(msg.sender == address(this), "Timelock::setDelay: Call must come from Timelock.");
require(delay_ >= MINIMUM_DELAY, "Timelock::setDelay: Delay must exceed minimum delay.");
require(delay_ <= MAXIMUM_DELAY, "Timelock::setDelay: Delay must not exceed maximum delay.");
delay = delay_;
emit NewDelay(delay);
}
Las funciones anteriores se explican por sí solas.
function setPendingAdmin(address pendingAdmin_) public {
require(msg.sender == address(this), "Timelock::setPendingAdmin: Call must come from Timelock.");
pendingAdmin = pendingAdmin_;
emit NewPendingAdmin(pendingAdmin);
}
function acceptAdmin() public {
require(msg.sender == pendingAdmin, "Timelock::acceptAdmin: Call must come from pendingAdmin.");
admin = msg.sender;
pendingAdmin = address(0);
emit NewAdmin(admin);
}
Estas dos funciones administran la propiedad del contrato.
Nota: ¿Solo el contrato puede llamar a setAdminPendente🧐?
¡Sí! Este control sobre los cambios de administrador está alineado con el concepto de gobernanza on-chain, donde dichas acciones se manejan como transacciones y requieren hacer fila.
function queueTransaction(address target, uint value, string memory signature, bytes memory data, uint eta) public returns (bytes32) {
require(msg.sender == admin, "Timelock::queueTransaction: Call must come from admin.");
require(eta >= getBlockTimestamp().add(delay), "Timelock::queueTransaction: Estimated execution block must satisfy delay.");
bytes32 txHash = keccak256(abi.encode(target, value, signature, data, eta));
queuedTransactions[txHash] = true;
emit QueueTransaction(txHash, target, value, signature, data, eta);
return txHash;
}
function cancelTransaction(address target, uint value, string memory signature, bytes memory data, uint eta) public {
require(msg.sender == admin, "Timelock::cancelTransaction: Call must come from admin.");
bytes32 txHash = keccak256(abi.encode(target, value, signature, data, eta));
queuedTransactions[txHash] = false;
emit CancelTransaction(txHash, target, value, signature, data, eta);
}
function executeTransaction(address target, uint value, string memory signature, bytes memory data, uint eta) public payable returns (bytes memory) {
require(msg.sender == admin, "Timelock::executeTransaction: Call must come from admin.");
bytes32 txHash = keccak256(abi.encode(target, value, signature, data, eta));
require(queuedTransactions[txHash], "Timelock::executeTransaction: Transaction hasn't been queued.");
require(getBlockTimestamp() >= eta, "Timelock::executeTransaction: Transaction hasn't surpassed time lock.");
require(getBlockTimestamp() <= eta.add(GRACE_PERIOD), "Timelock::executeTransaction: Transaction is stale.");
queuedTransactions[txHash] = false;
bytes memory callData;
if (bytes(signature).length == 0) {
callData = data;
} else {
callData = abi.encodePacked(bytes4(keccak256(bytes(signature))), data);
}
// solium-desabilitado-na-próxima-linha security/não-chama-valor
(bool success, bytes memory returnData) = target.call{value: value}(callData);
require(success, "Timelock::executeTransaction: Transaction execution reverted.");
emit ExecuteTransaction(txHash, target, value, signature, data, eta);
return returnData;
}
function getBlockTimestamp() internal view returns (uint) {
// solium-desabilitado-na-próxima-linha //segurança/sem-blocos-membros
return block.timestamp;
}
Aquí está la funcionalidad principal:
Transacción en Cola: el admin puede solicitar hacer la fila de una transacción especificando la dirección de destino, el valor, la firma de la función, los datos y el tiempo de ejecución estimado (eta). La solicitud se coloca en un hash, se marca como enfilado y se emite un evento para registrar la acción.
Cancelar Transacción: el admin puede cancelar una transacción en fila proporcionando los mismos parámetros utilizados durante la fila. Esta acción simplemente marca la transacción como no encolada y la registra.
Ejecutar Transacción: nuevamente, sólo el admin puede ejecutar una transacción en fila. El contrato verifica si la transacción estuvo en fila, si está dentro del tiempo definido y si no está retrasada (dentro del período de espera). Si todas las comprobaciones son exitosas, se ejecuta la transacción y se registra su resultado.
Es tan simple como eso y ahora, ¡tienes una idea de cómo funcionan los contratos inteligentes de Timelock en varios protocolos! 🕒💡
Espero sinceramente que este post haya sido informativo y te haya ayudado a comprender el Timelock. ¡Muchas gracias por dedicar tu tiempo a leerlo!
Si encontraste útil este post, considera compartirlo con tus amigos y colegas. ¡Tu apoyo significa mucho para mí! 🥳
Este artículo fue escrito por Srinivas Joshi y traducido por Juliana Cabeza. El original en inglés se puede encontrar aquí.
Discussion (0)