pa
Estaba pensando en por qué a los contratos inteligentes todavía les cuesta tomar decisiones basadas en la actividad histórica de la blockchain.
Pensemos en un protocolo de préstamos. Dos billeteras podrían tener exactamente el mismo saldo actual, pero sus historiales podrían ser completamente distintos. Una podría llevar años pidiendo préstamos y pagándolos responsablemente, mientras que la otra se creó ayer.
El contrato puede ver su estado actual. Pero ¿cómo evalúa todo lo que ocurrió antes?
Fue entonces cuando empecé a investigar más a fondo @SpaceandTime
Lo que me llamó la atención no fue simplemente que use Proof of SQL. Fue cómo un contrato inteligente recibe un resultado sin tener que realizar por sí mismo el cálculo en la base de datos.
Aquí hay una distinción importante.
Un contrato inteligente no se convierte de repente en una base de datos. Envía un plan de consulta SQL precompilado al QueryRouter de Space and Time, junto con un pago y un destino para la devolución de llamada.
La consulta se procesa en tablas de SXT Chain. El sistema genera una Proof of SQL junto con el resultado, y la prueba se verifica en la cadena antes de devolver el resultado al contrato solicitante.
Pero la devolución de llamada es otra parte interesante.
El contrato receptor debe comprobar que la respuesta provenga del ejecutor autorizado del enrutador y, luego, decodificar los datos recibidos antes de usarlos.
En otras palabras, recibir datos y actuar sobre ellos de forma segura son dos pasos distintos.
Esto cambia mi forma de pensar sobre la arquitectura. El cálculo pesado se realiza fuera del contrato solicitante, mientras que la verificación criptográfica permite que el contrato confíe en el resultado recibido sin procesar por su cuenta todo el conjunto de datos. Space and Time +1
Espera, hay otra capa que no quiero pasar por alto.
Una prueba válida no significa automáticamente que la información original fuera verdadera.
Si se introduce información incorrecta en una base de datos durante la ingesta, demostrar que un cálculo SQL se realizó correctamente sobre esos datos registrados no corrige mágicamente el error original. La integridad de los datos y su exactitud están relacionadas, pero no son lo mismo. Prueba .
@SpaceandTime #sxt $SXT
Estaba pensando en por qué a los contratos inteligentes todavía les cuesta tomar decisiones basadas en la actividad histórica de la blockchain.
Pensemos en un protocolo de préstamos. Dos billeteras podrían tener exactamente el mismo saldo actual, pero sus historiales podrían ser completamente distintos. Una podría llevar años pidiendo préstamos y pagándolos responsablemente, mientras que la otra se creó ayer.
El contrato puede ver su estado actual. Pero ¿cómo evalúa todo lo que ocurrió antes?
Fue entonces cuando empecé a investigar más a fondo @SpaceandTime
Lo que me llamó la atención no fue simplemente que use Proof of SQL. Fue cómo un contrato inteligente recibe un resultado sin tener que realizar por sí mismo el cálculo en la base de datos.
Aquí hay una distinción importante.
Un contrato inteligente no se convierte de repente en una base de datos. Envía un plan de consulta SQL precompilado al QueryRouter de Space and Time, junto con un pago y un destino para la devolución de llamada.
La consulta se procesa en tablas de SXT Chain. El sistema genera una Proof of SQL junto con el resultado, y la prueba se verifica en la cadena antes de devolver el resultado al contrato solicitante.
Pero la devolución de llamada es otra parte interesante.
El contrato receptor debe comprobar que la respuesta provenga del ejecutor autorizado del enrutador y, luego, decodificar los datos recibidos antes de usarlos.
En otras palabras, recibir datos y actuar sobre ellos de forma segura son dos pasos distintos.
Esto cambia mi forma de pensar sobre la arquitectura. El cálculo pesado se realiza fuera del contrato solicitante, mientras que la verificación criptográfica permite que el contrato confíe en el resultado recibido sin procesar por su cuenta todo el conjunto de datos. Space and Time +1
Espera, hay otra capa que no quiero pasar por alto.
Una prueba válida no significa automáticamente que la información original fuera verdadera.
Si se introduce información incorrecta en una base de datos durante la ingesta, demostrar que un cálculo SQL se realizó correctamente sobre esos datos registrados no corrige mágicamente el error original. La integridad de los datos y su exactitud están relacionadas, pero no son lo mismo. Prueba .
@SpaceandTime #sxt $SXT
