{"id":93794,"date":"2020-09-10T07:42:27","date_gmt":"2020-09-10T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne"},"modified":"2020-09-10T07:42:27","modified_gmt":"2020-09-10T05:42:27","slug":"town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: qual or\u00e1culo usar no blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hoje em dia, apenas os pregui\u00e7osos n\u00e3o escreveram sobre a tecnologia blockchain, criptomoedas e o qu\u00e3o incr\u00edvel isso \u00e9. Mas neste artigo n\u00e3o haver\u00e1 exalta\u00e7\u00e3o dessa tecnologia, em vez disso, abordaremos suas desvantagens e as solu\u00e7\u00f5es para elas. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Durante o trabalho em um dos projetos da Altyriks Systems, surgiu a tarefa de confirma\u00e7\u00e3o de dados de uma fonte externa para o blockchain que fosse segura e resistente \u00e0 censura. Era necess\u00e1rio confirmar as mudan\u00e7as nos registros de um terceiro sistema e, com base nessas mudan\u00e7as, executar uma ou outra ramifica\u00e7\u00e3o na l\u00f3gica do contrato inteligente. A princ\u00edpio, a tarefa parece bastante trivial, mas quando o resultado de sua execu\u00e7\u00e3o afeta a situa\u00e7\u00e3o financeira de uma das partes envolvidas no processo, surgem requisitos adicionais. Antes de tudo, \u00e9 necess\u00e1rio ter confian\u00e7a total em um mecanismo de valida\u00e7\u00e3o como esse. Mas vamos por partes. <\/p>\n

<\/a><\/noindex><\/p>\n

O problema \u00e9 que o blockchain \u00e9, por si s\u00f3, um objeto aut\u00f4nomo e fechado, ent\u00e3o os contratos inteligentes dentro do blockchain n\u00e3o sabem nada sobre o mundo exterior. Ao mesmo tempo, as condi\u00e7\u00f5es dos contratos inteligentes frequentemente est\u00e3o ligadas a informa\u00e7\u00f5es sobre coisas reais (atraso de voo, taxa de c\u00e2mbio, etc.). Para que os contratos inteligentes funcionem corretamente, as informa\u00e7\u00f5es obtidas de fora do blockchain devem ser confi\u00e1veis e verificadas. Esse problema \u00e9 resolvido com o uso de or\u00e1culos, como Town Crier e DECO. Esses or\u00e1culos permitem que um contrato inteligente na rede blockchain confie em informa\u00e7\u00f5es de um servidor web verificado, pode-se dizer que eles s\u00e3o fornecedores de informa\u00e7\u00f5es confi\u00e1veis. <\/p>\n

<\/p>\n

Or\u00e1culos<\/h1>\n

<\/p>\n

Imagine que um contrato inteligente realiza a transfer\u00eancia de 0,001 btc para sua carteira bitcoin caso seu clube de futebol favorito ven\u00e7a a Copa da R\u00fassia. Em caso de vit\u00f3ria real, o contrato inteligente precisa receber informa\u00e7\u00f5es sobre qual clube venceu, e aqui surgem uma s\u00e9rie de problemas: de onde obter essas informa\u00e7\u00f5es, como transmiti-las de forma segura para o contrato inteligente e como garantir que as informa\u00e7\u00f5es recebidas pelo contrato inteligente realmente correspondem \u00e0 realidade? <\/p>\n

<\/p>\n

Na quest\u00e3o da fonte de informa\u00e7\u00e3o, podem existir dois cen\u00e1rios: conectar um contrato inteligente a um site confi\u00e1vel, onde as informa\u00e7\u00f5es sobre os resultados das partidas s\u00e3o armazenadas de forma centralizada, ou a segunda op\u00e7\u00e3o \u2014 conectar v\u00e1rios sites e ent\u00e3o selecionar informa\u00e7\u00f5es da maioria das fontes que fornecem dados iguais. Para garantir a precis\u00e3o das informa\u00e7\u00f5es, s\u00e3o utilizados or\u00e1culos, como o Oraclize, que usa o TLSNotary (uma modifica\u00e7\u00e3o do TLS para provar a autenticidade dos dados). No entanto, h\u00e1 bastante informa\u00e7\u00e3o sobre o Oraclize no Google, e no Habr h\u00e1 v\u00e1rios artigos, hoje eu falarei sobre or\u00e1culos que utilizam uma abordagem um pouco diferente para a transmiss\u00e3o de informa\u00e7\u00f5es: Town Crier e DECO. O artigo descreve os princ\u00edpios de funcionamento de ambos os or\u00e1culos, bem como uma compara\u00e7\u00e3o detalhada. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

O Town Crier (TC) foi apresentado pelo IC3 (The Initiative for CryptoCurrencies and Contracts) em 2016 na CCS'16. A ideia principal do TC: transmitir informa\u00e7\u00f5es de um site para um contrato inteligente e garantir que as informa\u00e7\u00f5es entregues pelo TC sejam as mesmas que as do site. O TC utiliza TEE (Trusted Execution Environment) para a autenticidade da propriedade dos dados. Na vers\u00e3o original do TC, \u00e9 descrito o trabalho com o Intel SGX.
\nO Town Crier \u00e9 composto por uma parte dentro da blockchain e uma parte dentro do pr\u00f3prio sistema operacional \u2014 o TC Server.
\n\"Town
\nO TC Contract est\u00e1 na blockchain e atua como a interface do front end para o TC. Ele recebe solicita\u00e7\u00f5es do CU (contrato inteligente do usu\u00e1rio) e retorna a resposta do TC Server. Dentro do TC Server est\u00e1 o Relay, que estabelece a conex\u00e3o entre o enclave e a rede internet (tr\u00e1fego bidirecional) e conecta o enclave \u00e0 blockchain. O enclave cont\u00e9m progencl, que representa o c\u00f3digo que executa solicita\u00e7\u00f5es da blockchain e retorna mensagens para a blockchain com a assinatura digital; o progencl cont\u00e9m parte do c\u00f3digo do contrato inteligente e efetivamente executa algumas de suas fun\u00e7\u00f5es. <\/p>\n

<\/p>\n

O enclave Intel SGX pode ser visto como uma biblioteca comum com API, funcionando por meio de ecall. O ecall transfere o controle para o enclave. O enclave executa seu c\u00f3digo at\u00e9 que seja conclu\u00eddo ou ocorra uma exce\u00e7\u00e3o. Para chamar fun\u00e7\u00f5es definidas fora do enclave, s\u00e3o utilizados ocall. O ocall \u00e9 executado fora do enclave e \u00e9 tratado como uma chamada n\u00e3o confi\u00e1vel. Ap\u00f3s a execu\u00e7\u00e3o do ocall, o controle retorna ao enclave.
\n\"Town
\nNa parte do Enclave, \u00e9 configurado um canal seguro com o servidor web, onde o enclave realiza o handshake TLS com o servidor de destino e executa todas as opera\u00e7\u00f5es criptogr\u00e1ficas internamente. A biblioteca TLS (mbedTLS) e o c\u00f3digo HTTP em vers\u00e3o reduzida s\u00e3o exportados para o ambiente SGX. Al\u00e9m disso, o Enclave cont\u00e9m certificados root CA (cole\u00e7\u00e3o de certificados) para verificar os certificados dos servidores remotos. O Request Handler aceita um pedido datagrama no formato fornecido pelo Ethereum, descriptografa-o e analisa. Em seguida, gera uma transa\u00e7\u00e3o Ethereum contendo o datagrama solicitado, assina com skTC e envia ao Relay.<\/p>\n

<\/p>\n

A parte do Relay inclui a Client Interface, TCP e Blockchain Interface. A Client Interface \u00e9 necess\u00e1ria para a atesta\u00e7\u00e3o do c\u00f3digo do enclave e comunica\u00e7\u00e3o com o cliente. O cliente envia um pedido de atesta\u00e7\u00e3o usando ecall e recebe um timestamp, assinado por skTC, junto com o att (assinatura de atesta\u00e7\u00e3o), que \u00e9 ent\u00e3o confirmado pelo Intel Attestation Service (IAS), enquanto o timestamp \u00e9 verificado por um servi\u00e7o de tempo confi\u00e1vel. A Blockchain Interface verifica os pedidos recebidos e coloca transa\u00e7\u00f5es na blockchain para a entrega de datagrams. Geth \u00e9 o cliente oficial do Ethereum e permite que o Relay interaja com a blockchain atrav\u00e9s de chamadas RPC. <\/p>\n

<\/p>\n

Trabalhando com TEE, o TC permite iniciar v\u00e1rios enclaves simultaneamente, aumentando assim a velocidade de processamento de informa\u00e7\u00f5es em 3 vezes. Se com um enclave em funcionamento a velocidade era de 15 tx\/sec, com 20 enclaves iniciados em paralelo, a velocidade sobe para 65 tx\/sec; para compara\u00e7\u00e3o, a velocidade m\u00e1xima de opera\u00e7\u00e3o na blockchain do Bitcoin \u00e9 de 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Or\u00e1culos Descentralizados para TLS) foi apresentado no CCS\u201920, funciona com sites que suportam conex\u00e3o TLS. Garante a privacidade e a integridade dos dados.
\nO DECO com TLS utiliza criptografia sim\u00e9trica, fazendo com que tanto o cliente quanto o servidor web tenham chaves de criptografia, e o cliente, se desejar, pode falsificar os dados da sess\u00e3o TLS. Para resolver esse problema, o DECO utiliza um protocolo de handshake de tr\u00eas vias entre prover (smart contract), verifier (or\u00e1culo) e web-server (fonte de dados).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

O princ\u00edpio de funcionamento do DECO consiste em o verificador (prover) obter parte dos dados D e confirmar ao verificador (verifier) que D veio do servidor TLS S. Outro problema \u00e9 que o TLS n\u00e3o assina os dados, e o cliente TLS enfrenta dificuldades para provar que os dados foram obtidos daquele servidor espec\u00edfico (dificuldade de proveni\u00eancia). <\/p>\n

<\/p>\n

No protocolo DECO, s\u00e3o utilizados chaves de criptografia KEnc e KMac. O cliente envia uma solicita\u00e7\u00e3o Q para servidor web<\/a>, a resposta do servidor R chega de forma criptografada, mas tanto o cliente quanto o servidor possuem os mesmos KMac, permitindo que o cliente possa falsificar a mensagem TLS. A solu\u00e7\u00e3o do DECO consiste em 'esconder' o KMac do cliente (prover), at\u00e9 que ele responda \u00e0 solicita\u00e7\u00e3o. Agora, o KMac \u00e9 dividido entre prover e verificador \u2014 KpMac e KvMac. O servidor recebe o KMac para criptografar a resposta usando a opera\u00e7\u00e3o de partes da chave KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Configurando um handshake de tr\u00eas vias, a troca de dados entre o cliente e o servidor ser\u00e1 realizada com garantia de seguran\u00e7a.
\n\"Town
\nFalando sobre sistemas de or\u00e1culos descentralizados, n\u00e3o se pode deixar de mencionar a Chainlink, que busca criar uma rede descentralizada de n\u00f3s or\u00e1culos compat\u00edvel com Ethereum, Bitcoin e Hyperledger, considerando a modularidade: cada parte do sistema pode ser atualizada. Para garantir a seguran\u00e7a, a Chainlink oferece a cada or\u00e1culo envolvido na tarefa emitir uma combina\u00e7\u00e3o de chaves (p\u00fablica e privada). A chave privada \u00e9 utilizada para gerar uma assinatura parcial, que cont\u00e9m sua solu\u00e7\u00e3o para a solicita\u00e7\u00e3o de dados. Para obter uma resposta, \u00e9 necess\u00e1ria a combina\u00e7\u00e3o de todas as assinaturas parciais dos or\u00e1culos da rede.<\/p>\n

<\/p>\n

A Chainlink planeja realizar um PoC DECO inicial focado em aplica\u00e7\u00f5es financeiras descentralizadas, como Mixicles. No momento da reda\u00e7\u00e3o deste artigo, saiu uma not\u00edcia na Forbes informando que a Chainlink adquiriu a DECO da Cornell University.<\/p>\n

<\/p>\n

Ataques aos or\u00e1culos<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Do ponto de vista da seguran\u00e7a da informa\u00e7\u00e3o, foram considerados os seguintes ataques ao Town Crier:<\/p>\n

<\/p>\n

    \n
  1. \n

    Inje\u00e7\u00e3o de c\u00f3digo de smart contract malicioso em n\u00f3s TEE.
    \nA ess\u00eancia do ataque: a transmiss\u00e3o de c\u00f3digo de smart contract intencionalmente incorreto para o TEE, permitindo que um invasor que tenha acesso ao n\u00f3 possa executar seu pr\u00f3prio smart contract (fraudulento) sobre dados decifrados. No entanto, os valores retornados estar\u00e3o criptografados com a chave privada, e a \u00fanica maneira de acessar esses dados \u00e9 pela vazamento do texto criptografado durante a devolu\u00e7\u00e3o\/sa\u00edda.
    \nA prote\u00e7\u00e3o contra este ataque consiste em verificar pela enclave a veracidade do c\u00f3digo presente no endere\u00e7o atual. Isso pode ser alcan\u00e7ado por meio de um esquema de endere\u00e7amento, onde o endere\u00e7o do contrato \u00e9 definido pela hash do c\u00f3digo do contrato. <\/p>\n

    \n<\/li>\n

  2. \n

    Mudan\u00e7as no estado do contrato ciphertext vazam.
    \nO cerne do ataque: Os propriet\u00e1rios de n\u00f3s onde os contratos inteligentes s\u00e3o executados t\u00eam acesso ao estado do contrato de forma criptografada fora do enclave. Um invasor que controla um n\u00f3 pode comparar o estado do contrato antes e depois da execu\u00e7\u00e3o da transa\u00e7\u00e3o e pode determinar quais argumentos foram fornecidos e qual m\u00e9todo espec\u00edfico do contrato inteligente foi utilizado, uma vez que o c\u00f3digo do contrato inteligente e suas especifica\u00e7\u00f5es t\u00e9cnicas s\u00e3o de dom\u00ednio p\u00fablico.
    \nProte\u00e7\u00e3o para garantir a confiabilidade do pr\u00f3prio n\u00f3.<\/p>\n

    \n<\/li>\n

  3. \n

    Ataques de canal lateral.
    \nUm tipo especial de ataques que utiliza o monitoramento do acesso \u00e0 mem\u00f3ria e ao cache do enclave em v\u00e1rios cen\u00e1rios. Um exemplo desse tipo de ataque \u00e9 o Prime and Probe.
    \n\"Town
    \nSequ\u00eancia de execu\u00e7\u00e3o do ataque:<\/p>\n

    <\/p>\n