si ha estado siguiendo @SpaceandTimeDB, probablemente ha oído hablar de la prueba de SQL (nuestra novedosa prueba zk). así que hoy, lo guiaré a través de casos de uso del mundo real para la prueba de SQL con ejemplos que abarcan DeFi, oráculos, infraestructura entre cadenas, aprovisionamiento de liquidez e incluso instituciones. Primero, digamos que desea lanzar un token: $XYZ. Así que te acercas a una ballena y llegas a un acuerdo... "Oye, si agregas USD 1 millón en USDT a mi fondo de liquidez en Uniswap, te daré el 1% del suministro de $XYZ". Este acuerdo está escrito en un contrato inteligente, ¿sí? Pero entonces, el desafío ahora es que este contrato debe consultar y verificar que esta ballena realmente depositó lo que prometió para que pueda ser recompensada. Por lo tanto, necesita un contrato inteligente que: - verifica que esta ballena realmente agregó $1M USDT. - Rastrea la billetera + marca de tiempo. - Aplica la recompensa del token del 1%. pero ese $ 1 millón de USDT en realidad vive fuera de la cadena. prolly en un subgrafo dex o API de uniswap. Aquí es donde queremos traer la prueba de SQL. Por lo tanto, el depósito de liquidez de la ballena se consulta a través de SQL, luego se verifica criptográficamente y finalmente se introduce en el contrato inteligente con supuestos de confianza cero. El segundo es la responsabilidad del operador del nodo (recorte/recompensa). En redes como @chainlink o cualquier DEPIN, varios nodos realizan trabajos (obtener precios, verificar identidades, ejecutar computación, etc.) Cada nodo debe ser recompensado de manera justa y en consecuencia. Si hacen trampa o se desconectan, deben ser cortados. Pero hay un problema. ¿Cómo sabe el contrato inteligente qué nodo hizo qué trabajo? Tenga en cuenta que la actividad del operador está fuera de la cadena (a menudo almacenada en registros o bases de datos), por lo que usted, como operador de nodo, ¿no querría que los datos fueran precisos? Si estás a punto de ser cortado, quieres estar muy seguro de que te están cortando por una razón real. nuevamente, aquí viene la prueba de SQL al rescate. con Proof of SQL, la red puede: - Consulta de registros de finalización de trabajos. - Generar una prueba verificable del rendimiento del nodo. - Aliméntelo en cadena para automatizar la lógica de recompensa o corte. Entonces, al final, si te cortan, sabes por qué porque puedes ver un recibo criptográfico que demuestra que fue por una razón real. cuando se trata de verificación de garantías entre cadenas, todavía necesitamos la prueba de SQL. Supongamos que está construyendo un protocolo de préstamo en Base y Ethereum donde los usuarios depositan garantías en ambas cadenas. ¿Cómo se prueba el TVL total? ¿Cómo se monitorea el material de usuario en ambas cadenas? Además, ¿cómo se previene la doble contabilidad o el fraude? sin prueba de SQL, necesitaría: - Confía en las API personalizadas. - Confiar en los datos puente. - Centralizar el backend. :/ pero con la prueba de SQL, puede: - Consulta el estado de la cadena cruzada a partir de los datos de ambas cadenas. - Probarlo criptográficamente. - Utilice una vista única para impulsar préstamos, liquidaciones y tasas de interés. finalmente. Digamos que eres un gran banco Tradfi que busca tokenizar tus activos. Querrías: - lanzar RWA. - Prestar contra activos. - Demostrar solvencia o garantía a los clientes. Pero los datos de sus activos se encuentran en una base de datos fuera de la cadena. en lugar de volcar información confidencial en la cadena, puede usar la prueba de SQL para consultar su base de datos interna, generar una prueba criptográfica de saldos y demostrar la propiedad o el respaldo de los activos sin revelar datos reales. en esencia, ZK + SQL = privacidad de grado institucional + transparencia. si está construyendo un token con acuerdos de liquidez o ejecutando una red DePIN u oracle, o incluso implementando préstamos multicadena, necesitará datos verificables fuera de la cadena. y eso es lo que te da Proof of SQL by @SpaceandTimeDB.