pa
Eu estava pensando em por que os contratos inteligentes ainda têm dificuldade para tomar decisões usando atividades históricas de blockchain.
Pense em um protocolo de empréstimo. Duas carteiras podem ter exatamente o mesmo saldo atual, mas seus históricos podem ser completamente diferentes. Uma pode ter anos de empréstimos e pagamentos responsáveis, enquanto a outra foi criada ontem.
O contrato consegue ver o estado atual delas. Mas como ele avalia tudo o que aconteceu antes?
Foi aí que comecei a analisar mais de perto @SpaceandTime
O que me chamou a atenção não foi simplesmente o fato de ele usar Proof of SQL. Foi a maneira como um contrato inteligente recebe um resultado sem precisar executar o cálculo no banco de dados por conta própria.
Há uma distinção importante aqui.
Um contrato inteligente não se transforma de repente em um banco de dados. Ele envia um plano de consulta SQL pré-compilado ao QueryRouter da Space and Time, junto com um pagamento e um destino de callback.
A consulta é processada em tabelas na SXT Chain. O sistema gera uma Proof of SQL junto com o resultado, e a prova é verificada on-chain antes que o resultado seja devolvido ao contrato solicitante.
Mas o callback é outra parte interessante.
O contrato que recebe os dados precisa verificar se a resposta veio do executor autorizado do roteador e, em seguida, decodificar os dados retornados antes de usá-los.
Em outras palavras, receber dados e agir com segurança com base neles são duas etapas diferentes.
Isso muda a forma como penso na arquitetura. O processamento pesado acontece fora do contrato solicitante, enquanto a verificação criptográfica permite que o contrato confie no resultado retornado sem processar independentemente todo o conjunto de dados. Space and Time +1
Espere, há mais uma camada que não quero deixar passar.
Uma prova válida não significa automaticamente que a informação original era verdadeira.
Se informações incorretas forem inseridas em um banco de dados durante a ingestão, provar que um cálculo SQL foi executado corretamente sobre esses dados registrados não corrige magicamente o erro original. Integridade dos dados e precisão dos dados estão relacionadas, mas não são a mesma coisa. Proof .
@SpaceandTime #sxt $SXT
Eu estava pensando em por que os contratos inteligentes ainda têm dificuldade para tomar decisões usando atividades históricas de blockchain.
Pense em um protocolo de empréstimo. Duas carteiras podem ter exatamente o mesmo saldo atual, mas seus históricos podem ser completamente diferentes. Uma pode ter anos de empréstimos e pagamentos responsáveis, enquanto a outra foi criada ontem.
O contrato consegue ver o estado atual delas. Mas como ele avalia tudo o que aconteceu antes?
Foi aí que comecei a analisar mais de perto @SpaceandTime
O que me chamou a atenção não foi simplesmente o fato de ele usar Proof of SQL. Foi a maneira como um contrato inteligente recebe um resultado sem precisar executar o cálculo no banco de dados por conta própria.
Há uma distinção importante aqui.
Um contrato inteligente não se transforma de repente em um banco de dados. Ele envia um plano de consulta SQL pré-compilado ao QueryRouter da Space and Time, junto com um pagamento e um destino de callback.
A consulta é processada em tabelas na SXT Chain. O sistema gera uma Proof of SQL junto com o resultado, e a prova é verificada on-chain antes que o resultado seja devolvido ao contrato solicitante.
Mas o callback é outra parte interessante.
O contrato que recebe os dados precisa verificar se a resposta veio do executor autorizado do roteador e, em seguida, decodificar os dados retornados antes de usá-los.
Em outras palavras, receber dados e agir com segurança com base neles são duas etapas diferentes.
Isso muda a forma como penso na arquitetura. O processamento pesado acontece fora do contrato solicitante, enquanto a verificação criptográfica permite que o contrato confie no resultado retornado sem processar independentemente todo o conjunto de dados. Space and Time +1
Espere, há mais uma camada que não quero deixar passar.
Uma prova válida não significa automaticamente que a informação original era verdadeira.
Se informações incorretas forem inseridas em um banco de dados durante a ingestão, provar que um cálculo SQL foi executado corretamente sobre esses dados registrados não corrige magicamente o erro original. Integridade dos dados e precisão dos dados estão relacionadas, mas não são a mesma coisa. Proof .
@SpaceandTime #sxt $SXT
