DeFi vs TradFi: arquitectura, liquidación y riesgo comparados

Alcance y la distinción central

La comparación DeFi vs TradFi suele enmarcarse como descentralización versus centralización, pero ese marco oculta las diferencias operativas que importan a los desarrolladores y analistas. Un eje más útil es: quién mantiene el libro mayor autoritativo, quién puede revertir una transacción y quién absorbe las pérdidas cuando algo falla. TradFi mantiene registros autoritativos dentro de instituciones reguladas y sistemas de liquidación; DeFi los mantiene en el estado público de una blockchain que cualquiera puede leer y que cualquiera con claves puede modificar.

Este artículo cubre cuatro capas: custodia, liquidación, crédito y liquidez, y riesgo. Luego muestra cómo medir el comportamiento del lado DeFi con llamadas JSON-RPC estándar para que las comparaciones se basen en datos observados y no en afirmaciones de marketing. La selección concreta de endpoints queda fuera del alcance aquí; para eso, utilice la guía del Asistente RPC sobre cómo elegir un proveedor RPC de Web3.

• TradFi: participación con permisos, finalidad legal, custodia institucional.
• DeFi: participación sin permisos, finalidad probabilística o económica, autocustodia.
• Ambos: descubrimiento de precios, extensión de crédito, gestión de colateral y extracción de comisiones.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que tiene un endpoint HTTP JSON-RPC para una red compatible con EVM, un shell con curl y, opcionalmente, Node.js o Python para los ejemplos de múltiples llamadas. Reemplace RPC_URL con su propio endpoint; nunca pegue claves de producción en scripts compartidos. Para acceso gestionado con límites de velocidad y enrutamiento multicadena, consulte servicio API de OnFinality y precios de RPC.

También debe saber qué cadena está consultando. Las direcciones de contratos, los tiempos de bloque y los supuestos de finalidad difieren por red; el directorio de redes compatibles enumera lo disponible. Si necesita un rendimiento predecible para mediciones repetidas, un nodo dedicado elimina los efectos de vecinos ruidosos que introducen los endpoints públicos.

Custodia y el libro mayor autoritativo

En TradFi, su saldo en un banco es un pasivo de ese banco registrado en su libro mayor interno. Usted no posee el activo subyacente; posee un derecho, y la solvencia del banco y el régimen de seguro de depósitos determinan su riesgo real. En DeFi, su saldo es una entrada en el almacenamiento de un contrato público. Usted posee claves y el código del contrato determina qué puede hacer con el saldo.

Esta diferencia cambia los modos de fallo. Un fallo de custodia en TradFi es un evento institucional y legal resuelto mediante regímenes de resolución y seguros. Un fallo de custodia en DeFi suele ser un evento de gestión de claves o de lógica de contrato sin una contraparte a la que apelar. La implicación práctica: en DeFi, verificar el comportamiento del contrato antes de depositar es parte de la custodia, no un paso de auditoría separado.

Liquidación, finalidad y reversibilidad

La liquidación en TradFi es por lotes e intermediada. Un pago con tarjeta, una transferencia o una operación de valores se liquida a través de miembros compensadores y depositarios centrales de valores, con ventanas de reversión definidas y reglas de contracargo. La finalidad es legal: una vez que se completa el ciclo de liquidación y se aplica la ley correspondiente, la transferencia se considera final incluso si la base de datos subyacente pudiera editarse técnicamente.

La liquidación en DeFi es continua y pública. Una transacción se incluye en un bloque y luego gana finalidad económica a medida que se producen más bloques sobre ella. La reversibilidad existe solo mediante reorganizaciones del consenso o, en algunos sistemas, acciones de gobernanza explícitas. La consecuencia para la medición es que 'liquidado' es una distribución, no un booleano: debe registrar el tiempo de inclusión y la profundidad de confirmación en lugar de asumir una finalidad instantánea.

• Registre la marca de tiempo del bloque en la inclusión y en N confirmaciones.
• Compárela con la regla de finalidad documentada de la cadena, no con un número genérico.
• Trate el riesgo de reorganización como una función de la cadena y la profundidad de confirmación, no como una constante.

Crédito, liquidez y quién soporta la pérdida

La creación de crédito en TradFi se ejecuta a través de balances regulados: los bancos originan préstamos, mantienen capital contra ellos y son supervisados. Las pérdidas son absorbidas por el capital, luego por los depositantes dentro de los límites asegurados y luego por las autoridades de resolución. El crédito en DeFi se ejecuta a través de pools sobrecolateralizados y mercados de préstamo: los prestatarios depositan colateral, los liquidadores cierran posiciones cuando los ratios de colateral caen y las pérdidas recaen sobre los depositantes y, en algunos diseños, sobre un fondo de respaldo o seguro.

Esto hace que la profundidad de liquidez y el comportamiento de liquidación en DeFi sean medibles de una manera que el crédito TradFi no lo es. Puede leer las reservas del pool, la utilización y los umbrales de liquidación directamente del estado del contrato. La contrapartida es que el crédito DeFi es ineficiente en capital (sobrecolateralizado) y está expuesto a fallos de oráculos y de mecanismos de liquidación, mientras que el crédito TradFi es eficiente en capital pero opaco para observadores externos.

Medición del tiempo de liquidación en DeFi con JSON-RPC

El siguiente procedimiento registra el tiempo de inclusión y la profundidad de confirmación de una transacción. Es una medición que usted ejecuta; el resultado depende de la cadena y del momento de la consulta, así que no trate ningún resultado individual como un punto de referencia. Ejecútelo varias veces y reporte una distribución.

Primero, obtenga la transacción y su recibo, luego obtenga el número de bloque actual para calcular la profundidad:

• Extraiga blockNumber del recibo y compárelo con el número de bloque más reciente.
• Obtenga el bloque con eth_getBlockByNumber para leer su marca de tiempo.
• Repita a intervalos para observar cómo crece la profundidad con el tiempo.

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0xYOUR_TX_HASH"]}'

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

Medición de la autoridad de actualización de contratos y el riesgo de administrador

Un riesgo central de DeFi que no tiene equivalente en TradFi de la misma forma es la autoridad de actualización: un administrador de proxy o una multifirma de gobernanza puede cambiar la lógica del contrato después de que usted deposite. Puede inspeccionar esto directamente. Lea el slot de implementación de un proxy EIP-1967 y verifique quién controla el administrador.

El fragmento a continuación lee el slot de implementación y el slot de administrador usando eth_getStorageAt. Compare las direcciones devueltas con la documentación de gobernanza publicada del proyecto; una discrepancia es un hallazgo, no necesariamente un fallo.

const RPC_URL = process.env.RPC_URL;
const PROXY = "0xYOUR_PROXY_ADDRESS";
const IMPL_SLOT = "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc";
const ADMIN_SLOT = "0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103";

async function slot(slotHex) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0", id: 1, method: "eth_getStorageAt",
      params: [PROXY, slotHex, "latest"]
    })
  });
  const json = await res.json();
  return "0x" + json.result.slice(-40);
}

(async () => {
  console.log("implementation:", await slot(IMPL_SLOT));
  console.log("admin:", await slot(ADMIN_SLOT));
})();

Tabla de resultados y cómo completarla

Utilice una tabla como la siguiente para registrar sus propias observaciones. Deje las celdas en blanco hasta que las haya medido; no copie valores de otras fuentes en una tabla de resultados, porque las condiciones de la cadena y los despliegues de contratos cambian. La tabla es una plantilla, no un conjunto de hallazgos.

Complete la tabla ejecutando los procedimientos de este artículo contra la misma cadena y ventana temporal. Si compara dos pools o dos cadenas, mantenga constante el método de consulta para que las diferencias reflejen el sistema, no sus herramientas.

Verificación y observaciones esperadas

Después de ejecutar el procedimiento de liquidación, debería ver que el blockNumber del recibo se estabiliza y que la profundidad calculada aumenta monotónicamente a medida que llegan nuevos bloques. Si la profundidad disminuye, es probable que esté consultando endpoints diferentes o que haya ocurrido una reorganización; vuelva a consultar contra un único endpoint y registre la identidad del endpoint junto con el resultado.

Después de ejecutar el procedimiento de slots de almacenamiento, debería ver una dirección de implementación distinta de cero para un contrato proxy y una dirección de administrador que coincida con el controlador documentado del proyecto. Un slot de administrador cero en un proxy es en sí mismo un hallazgo que vale la pena investigar, porque puede indicar un patrón de proxy no inicializado o no estándar.

Solución de problemas de mediciones inconsistentes

La causa más común de mediciones DeFi inconsistentes es la inconsistencia de endpoints: diferentes proveedores RPC pueden servir cabezas de cadena ligeramente distintas, por lo que una consulta 'latest' contra dos endpoints puede discrepar. Fije un único endpoint por ejecución de medición y registre su identidad. Si necesita lecturas multicadena consistentes, una capa multicadena gestionada como la descrita en la guía de endpoints RPC multicadena reduce este tipo de error.

La segunda causa común es que el estado del contrato cambie entre llamadas. Lea los valores relacionados en el mismo bloque pasando un número de bloque explícito a eth_call y eth_getStorageAt en lugar de 'latest'. La tercera es la limitación de velocidad: los endpoints públicos pueden limitar silenciosamente, devolviendo respuestas obsoletas o de error. Si ve fallos intermitentes, consulte la guía de confiabilidad de RPC y considere un nodo dedicado para ejecuciones repetibles.

• Fije un endpoint por ejecución y registre su URL.
• Utilice números de bloque explícitos para la consistencia de múltiples llamadas.
• Distinga las reorganizaciones de la discrepancia entre endpoints volviendo a consultar el mismo hash.

Limitaciones y compensaciones de la comparación

Esta comparación es estructural, no un veredicto. TradFi ofrece recurso legal, seguro de depósitos y mercados de crédito maduros, a costa de opacidad e intermediación. DeFi ofrece transparencia, composabilidad y autocustodia, a costa de riesgo de código, riesgo de oráculos y errores irreversibles. Ninguna propiedad es universalmente mejor; la elección correcta depende de si valora más el recurso o la verificabilidad en un caso de uso dado.

La medición también tiene límites. Los datos on-chain muestran lo que hicieron los contratos, no por qué, y no pueden capturar acuerdos legales fuera de la cadena que puedan respaldar un activo tokenizado. Trate las métricas on-chain como una entrada y combínelas con la revisión de documentación y, cuando corresponda, informes de auditoría.

Próximos pasos para desarrolladores y analistas

Si está construyendo una integración DeFi, comience mapeando la autoridad de actualización del contrato y las dependencias de oráculos, luego mida el comportamiento de liquidación y liquidez en la cadena que pretende usar. Si está analizando la frontera entre DeFi y TradFi, extienda la medición a activos del mundo real tokenizados y reservas de stablecoins, donde ambos sistemas se superponen cada vez más.

Para cargas de trabajo en producción, pase de endpoints públicos ad-hoc a una capa RPC gestionada o dedicada para que sus mediciones y su aplicación vean una cabeza de cadena consistente. Revise el servicio API de OnFinality, los precios de RPC y las opciones de nodo dedicado antes de comprometerse, y consulte al Asistente RPC para recomendaciones concretas de endpoints en lugar de adivinar a partir de listas públicas.