{"id":34101,"date":"2019-10-31T21:56:25","date_gmt":"2019-10-31T18:56:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ob-anonimnosti-v-account-based-blokchejnah\/"},"modified":"2019-10-31T21:56:25","modified_gmt":"2019-10-31T18:56:25","slug":"ob-anonimnosti-v-account-based-blokchejnah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"Sobre a anonimidade em blockchains baseadas em contas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Estamos interessados h\u00e1 muito tempo na quest\u00e3o da anonimidade nas criptomoedas e tentamos acompanhar o desenvolvimento das tecnologias nessa \u00e1rea. Em nossos artigos, j\u00e1 discutimos detalhadamente os princ\u00edpios de funcionamento transa\u00e7\u00f5es confidenciais<\/a><\/noindex> no Monero, assim como fizemos um revista comparativa<\/a><\/noindex> das tecnologias existentes nesse campo. No entanto, todas as criptomoedas an\u00f4nimas atualmente s\u00e3o baseadas no modelo de dados proposto pelo Bitcoin \u2014 Unspent Transaction Output (UTXO). Para blockchains baseados em conta, como o Ethereum, as solu\u00e7\u00f5es existentes para implementar anonimidade e confidencialidade (por exemplo, Mobius<\/a><\/noindex> ou Aztec<\/a><\/noindex>) tentaram replicar o modelo UTXO em contratos inteligentes.<\/p>\n

Em fevereiro de 2019, um grupo de pesquisadores da Universidade de Stanford e da Visa Research<\/a><\/noindex> lan\u00e7amos publicou um pr\u00e9-print<\/a><\/noindex> intitulado \"Zether: Em Dire\u00e7\u00e3o \u00e0 Privacidade no Mundo dos Contratos Inteligentes\". Os autores propuseram pela primeira vez uma abordagem para garantir anonimidade em blockchains baseados em conta e apresentaram duas variantes de contratos inteligentes: para transa\u00e7\u00f5es confidenciais (oculta\u00e7\u00e3o de saldos e valores de transfer\u00eancias) e an\u00f4nimas (oculta\u00e7\u00e3o do recipiente e do remetente). Achamos a tecnologia proposta interessante e gostar\u00edamos de compartilhar como ela funciona, al\u00e9m de discutir por que a quest\u00e3o da anonimidade em blockchains baseados em conta \u00e9 considerada muito complexa e se os autores conseguiram resolv\u00ea-la completamente.<\/p>\n

Sobre o funcionamento desses modelos de dados<\/h3>\n

\nNo modelo UTXO, uma transa\u00e7\u00e3o consiste em \"entradas\" e \"sa\u00eddas\". O equivalente direto \u00e0s \"sa\u00eddas\" s\u00e3o as c\u00e9dulas em sua carteira: cada \"sa\u00edda\" tem um determinado valor. Quando voc\u00ea paga a algu\u00e9m (forma uma transa\u00e7\u00e3o), voc\u00ea gasta uma ou mais \"sa\u00eddas\", tornando-as \"entradas\" na transa\u00e7\u00e3o, e a blockchain as marca como gastas. O recipiente do seu pagamento (ou voc\u00ea mesmo, se precisar de troco) recebe novas \"sa\u00eddas\" geradas. Esquematicamente, isso pode ser representado assim:<\/p>\n

\"Sobre
\n
\nBlockchains baseados em conta funcionam de maneira semelhante \u00e0 sua conta banc\u00e1ria. Eles operam apenas com o saldo da sua conta e o valor da transfer\u00eancia. Quando voc\u00ea transfere um valor da sua conta, n\u00e3o queima nenhuma \"sa\u00edda\", e a rede n\u00e3o precisa lembrar quais moedas foram gastas e quais n\u00e3o foram. No caso mais simples, a verifica\u00e7\u00e3o da transa\u00e7\u00e3o se resume a verificar a assinatura do remetente e o saldo de sua conta:<\/p>\n

\"Sobre
\n<\/p>\n

An\u00e1lise da tecnologia<\/h3>\n

\nA seguir, vamos discutir como o Zether oculta o valor das transa\u00e7\u00f5es, o destinat\u00e1rio e o remetente. Ao descrever os princ\u00edpios de seu funcionamento, destacaremos as diferen\u00e7as entre as vers\u00f5es confidencial e an\u00f4nima. Como garantir a confidencialidade em blockchains baseadas em contas \u00e9 muito mais f\u00e1cil, algumas das limita\u00e7\u00f5es impostas pela anonimiza\u00e7\u00e3o n\u00e3o ser\u00e3o relevantes para a vers\u00e3o confidencial da tecnologia.<\/p>\n

Oculta\u00e7\u00e3o de saldos e valores das transfer\u00eancias<\/h4>\n

\nPara a criptografia dos saldos e valores das transfer\u00eancias no Zether, \u00e9 utilizada um esquema de criptografia de ElGamal<\/a><\/noindex>. Funciona da seguinte forma. Quando Alice quer enviar a Bob b<\/b><\/i> moedas para o endere\u00e7o (sua chave p\u00fablica) Y<\/b><\/i>, ela escolhe um n\u00famero aleat\u00f3rio r<\/b><\/i> e criptografa o valor:<\/p>\n

\"Sobre
\nonde C<\/b><\/i> \u2014 valor criptografado, D<\/b><\/i> \u2014 valor auxiliar necess\u00e1rio para descriptografar esse valor, G<\/b><\/i> \u2014 um ponto fixo na curva el\u00edptica, a multiplica\u00e7\u00e3o da qual pelo segredo resulta na chave p\u00fablica.<\/p>\n

Quando Bob recebe esses valores, ele simplesmente os acrescenta ao seu saldo, que tamb\u00e9m est\u00e1 criptografado, o que torna esse esquema conveniente.<\/p>\n

Da mesma forma, Alice subtrai de seu saldo os mesmos valores, usando como Y<\/b><\/i> sua chave p\u00fablica.<\/p>\n

Oculta\u00e7\u00e3o do destinat\u00e1rio e do remetente<\/h4>\n

\nA mistura de 'sa\u00eddas' em UTXO surgiu desde os prim\u00f3rdios das criptomoedas e ajuda a ocultar o remetente. Para isso, o pr\u00f3prio remetente, ao realizar a transfer\u00eancia, seleciona 'sa\u00eddas' aleat\u00f3rias na blockchain e as mistura com as suas. Em seguida, assina as 'sa\u00eddas' com uma assinatura em anel \u2014 um mecanismo criptogr\u00e1fico que permite convencer o verificador de que entre as 'sa\u00eddas' misturadas est\u00e3o as moedas do remetente. As moedas misturadas, \u00e9 claro, n\u00e3o s\u00e3o gastas.<\/p>\n

No entanto, para ocultar o destinat\u00e1rio, n\u00e3o conseguiremos gerar 'sa\u00eddas' falsas. Portanto, em UTXO, cada 'sa\u00edda' tem seu pr\u00f3prio endere\u00e7o \u00fanico, que est\u00e1 criptograficamente ligado ao endere\u00e7o do destinat\u00e1rio dessas moedas. Atualmente, n\u00e3o h\u00e1 como identificar a conex\u00e3o entre o endere\u00e7o \u00fanico da 'sa\u00edda' e o endere\u00e7o do destinat\u00e1rio sem conhecer suas chaves secretas.<\/p>\n

No modelo baseado em contas, n\u00e3o podemos usar endere\u00e7os tempor\u00e1rios (caso contr\u00e1rio, isso j\u00e1 seria um modelo de \"sa\u00eddas\"). Portanto, \u00e9 necess\u00e1rio misturar o destinat\u00e1rio e o remetente entre outras contas na blockchain. Nesse processo, as contas misturadas s\u00e3o debitadas de 0 moedas criptografadas (ou adicionadas com 0 \u2014 no caso da mistura do destinat\u00e1rio), sem mudar seu saldo real.<\/p>\n

Como o remetente e o destinat\u00e1rio sempre t\u00eam um endere\u00e7o fixo, surge a necessidade de usar os mesmos grupos para mistura em transfer\u00eancias para os mesmos endere\u00e7os. \u00c9 mais f\u00e1cil entender isso com um exemplo.<\/p>\n

Suponha que Alice decidiu fazer uma doa\u00e7\u00e3o para a organiza\u00e7\u00e3o de caridade de Bob, mas prefere que essa transfer\u00eancia permane\u00e7a an\u00f4nima para um observador externo. Assim, para se ocultar no campo do remetente, ela insere as contas de Adam e Adele. E para esconder Bob \u2014 no campo do destinat\u00e1rio, ela adiciona as contas de Ben e Bill. Na pr\u00f3xima doa\u00e7\u00e3o, Alice decidiu adicionar Alex e Amanda ao seu campo e Bruce e Benjamin ao de Bob. Neste caso, ao analisar a blockchain, haver\u00e1 apenas um par de participantes sobreposto nessas duas transa\u00e7\u00f5es \u2014 Alice e Bob, o que desanonimiza essas transa\u00e7\u00f5es.<\/p>\n

\"Sobre
\n<\/p>\n

Corridas de Transa\u00e7\u00f5es<\/h4>\n

\nComo j\u00e1 mencionamos, para ocultar seu saldo em sistemas baseados em contas, o usu\u00e1rio cifra seu saldo e o valor da transfer\u00eancia. Neste processo, ele deve provar que o saldo em sua conta permanece n\u00e3o negativo. O problema \u00e9 que, ao criar uma transa\u00e7\u00e3o, o usu\u00e1rio constr\u00f3i a prova em rela\u00e7\u00e3o ao seu estado atual da conta. E se Bob enviar uma transa\u00e7\u00e3o para Alice, e ela for aceita antes da enviada por Alice? Ent\u00e3o, a transa\u00e7\u00e3o de Alice ser\u00e1 considerada inv\u00e1lida, pois a prova de saldo foi constru\u00edda antes da aceita\u00e7\u00e3o da transa\u00e7\u00e3o de Bob.<\/p>\n

\"Sobre
\n
\nA primeira solu\u00e7\u00e3o que vem \u00e0 mente em tal situa\u00e7\u00e3o \u00e9 congelar a conta at\u00e9 a realiza\u00e7\u00e3o da transa\u00e7\u00e3o. Mas essa abordagem n\u00e3o \u00e9 vi\u00e1vel, pois al\u00e9m da complexidade de resolver essa tarefa em um sistema distribu\u00eddo, em um esquema an\u00f4nimo, n\u00e3o fica claro qual conta deve ser bloqueada.<\/p>\n

Para resolver esse problema, a tecnologia separa transa\u00e7\u00f5es de entrada e sa\u00edda: o gasto de fundos tem um efeito imediato no saldo, enquanto as receitas t\u00eam um efeito retardado. Para isso, introduz-se o conceito de \"\u00e9pocas\" \u2014 grupos de blocos de tamanho fixo. A \"\u00e9poca\" atual \u00e9 determinada pela divis\u00e3o da altura do bloco pelo tamanho do grupo. Ao processar uma transa\u00e7\u00e3o, a rede atualiza imediatamente o saldo do remetente, enquanto os fundos do destinat\u00e1rio s\u00e3o acumulados. Os fundos acumulados ficam dispon\u00edveis para o destinat\u00e1rio do pagamento somente com o in\u00edcio de uma nova \"\u00e9poca\".<\/p>\n

Como resultado, o usu\u00e1rio pode enviar transa\u00e7\u00f5es independentemente de qu\u00e3o frequentemente ele recebe fundos (dentro do que seu saldo permitir, \u00e9 claro). O tamanho da \u00e9poca \u00e9 determinado com base na rapidez com que os blocos se espalham pela rede e qu\u00e3o r\u00e1pido uma transa\u00e7\u00e3o entra em um bloco. <\/p>\n

Essa solu\u00e7\u00e3o funciona bem em casos de transfer\u00eancias confidenciais, no entanto, com transa\u00e7\u00f5es an\u00f4nimas, como veremos mais adiante, ela cria s\u00e9rios problemas.<\/p>\n

Prote\u00e7\u00e3o contra ataques de repeti\u00e7\u00e3o<\/h4>\n

\nEm blockchains baseados em contas, cada transa\u00e7\u00e3o \u00e9 assinada pela chave privada do remetente, o que convence o verificador de que a transa\u00e7\u00e3o n\u00e3o foi alterada e foi criada pelo propriet\u00e1rio dessa chave. Mas o que acontece se um invasor que est\u00e1 ouvindo o canal de transmiss\u00e3o interceptar essa mensagem e enviar uma segunda exatamente igual? O verificador ir\u00e1 comparar a assinatura da transa\u00e7\u00e3o e ficar\u00e1 convencido de sua autoria, e a rede ir\u00e1 deduzir a mesma quantia do saldo do remetente novamente.<\/p>\n

Esse ataque \u00e9 chamado de ataque de repeti\u00e7\u00e3o. No modelo UTXO, tais ataques n\u00e3o s\u00e3o relevantes, pois o invasor tentaria usar sa\u00eddas gastas, o que por si s\u00f3 n\u00e3o \u00e9 v\u00e1lido e \u00e9 rejeitado pela rede.<\/p>\n

Para evitar que isso aconte\u00e7a, uma campo com dados aleat\u00f3rios \u00e9 embutido na transa\u00e7\u00e3o, que \u00e9 chamado de nonce ou simplesmente \"sal\". Ao re-enviar a transa\u00e7\u00e3o com o \"sal\", o verificador verifica se esse nonce j\u00e1 foi utilizado anteriormente e, se n\u00e3o, considera a transa\u00e7\u00e3o v\u00e1lida. Para n\u00e3o armazenar todo o hist\u00f3rico de nonces dos usu\u00e1rios na blockchain, geralmente na primeira transa\u00e7\u00e3o ele \u00e9 considerado igual a zero e depois aumenta em um. A rede s\u00f3 precisa verificar se o nonce da nova transa\u00e7\u00e3o \u00e9 diferente do anterior por um unidade.<\/p>\n

Em um esquema an\u00f4nimo de transfer\u00eancias, surge o problema da valida\u00e7\u00e3o dos nonces das transa\u00e7\u00f5es. N\u00e3o podemos vincular o nonce explicitamente ao endere\u00e7o do remetente, pois isso, evidentemente, desanonimiza a transfer\u00eancia. Tamb\u00e9m n\u00e3o podemos incrementar os nonces de todas as contas envolvidas, pois isso pode entrar em conflito com outras transfer\u00eancias que est\u00e3o sendo processadas. <\/p>\n

Os autores do Zether sugerem gerar o nonce criptograficamente \u2014 dependendo da \"\u00e9poca\". Por exemplo:<\/p>\n

\"Sobre
\nAqui x<\/i><\/b> \u2014 a chave secreta do remetente, e Gepoch<\/i><\/b> \u2014 um gerador adicional para a \u00e9poca, obtido pela hash de uma string do tipo 'Zether + '. Agora, o problema, aparentemente, \u00e9 resolvido \u2014 n\u00e3o revelamos o nonce do remetente e n\u00e3o interferimos nos nonces de participantes n\u00e3o envolvidos. Mas essa abordagem imp\u00f5e uma limita\u00e7\u00e3o s\u00e9ria: uma conta pode enviar no m\u00e1ximo uma transa\u00e7\u00e3o por '\u00e9poca'. Esse problema, infelizmente, permanece sem solu\u00e7\u00e3o e, no momento, torna a vers\u00e3o an\u00f4nima do Zether, a nosso ver, pouco utiliz\u00e1vel.<\/p>\n

Dificuldade das provas de zero conhecimento<\/h4>\n

\nNo UTXO, o remetente deve provar \u00e0 rede que n\u00e3o est\u00e1 gastando um montante negativo, caso contr\u00e1rio, a gera\u00e7\u00e3o de novas moedas do nada se torna poss\u00edvel (por que isso \u00e9 poss\u00edvel, escrevemos em uma das anteriores de artigos<\/a><\/noindex>). E tamb\u00e9m assinar as \"entradas\" com uma assinatura em anel, para provar que entre as moedas misturadas existem fundos que lhe pertencem.<\/p>\n

Na vers\u00e3o an\u00f4nima de um blockchain baseado em contas, as express\u00f5es para prova tornam-se muito mais complexas. O remetente prova que:<\/p>\n

    \n
  1. O montante enviado \u00e9 positivo;<\/li>\n
  2. O saldo permanece n\u00e3o negativo;<\/li>\n
  3. O remetente criptografou corretamente os montantes das transfer\u00eancias (incluindo os nulos);<\/li>\n
  4. O saldo s\u00f3 muda para o remetente e o destinat\u00e1rio;<\/li>\n
  5. O remetente possui a chave secreta da sua conta e realmente est\u00e1 na lista de remetentes (entre os misturados);<\/li>\n
  6. O nonce utilizado na transa\u00e7\u00e3o \u00e9 formado corretamente.<\/li>\n<\/ol>\n

    \nPara tal prova complexa, os autores utilizam uma mistura Bulletproof<\/a><\/noindex> (um dos autores, a prop\u00f3sito, participou de sua cria\u00e7\u00e3o) e Sigma protocol<\/a><\/noindex>, a qual chamam de Sigma-bullets. A prova formal de tal afirma\u00e7\u00e3o \u00e9 uma tarefa bastante complicada e limita fortemente o n\u00famero de interessados em implementar a tecnologia.<\/p>\n

    Qual \u00e9 o resultado?<\/h4>\n

    \nNa nossa opini\u00e3o, a parte Zether que traz privacidade para blockchains baseados em contas pode ser utilizada j\u00e1 agora. Mas, neste momento, a vers\u00e3o an\u00f4nima da tecnologia imp\u00f5e s\u00e9rias limita\u00e7\u00f5es ao seu uso, e sua complexidade dificulta a implementa\u00e7\u00e3o. No entanto, n\u00e3o devemos desconsiderar o fato de que os autores a lan\u00e7aram apenas h\u00e1 alguns meses, e talvez algu\u00e9m encontre uma solu\u00e7\u00e3o para os problemas atuais. Afinal, \u00e9 assim que a ci\u00eancia avan\u00e7a.
    \n
    Fonte:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u0443\u0436\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u043b\u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 Monero, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043d\u0430 \u044d\u0442\u043e\u043c \u043f\u043e\u043b\u0435. \u041e\u0434\u043d\u0430\u043a\u043e \u0436\u0435 \u0432\u0441\u0435 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u044b \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u043d\u0430 \u043c\u043e\u0434\u0435\u043b\u0438 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u043d\u043e\u0439 Bitcoin \u2014 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34101","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sobre a anonimidade em blockchains baseados em contas | ProHoster","description":"Estamos h\u00e1 bastante tempo interessados no tema da anonimidade em criptomoedas e nos esfor\u00e7amos para acompanhar o desenvolvimento de tecnologias nesta \u00e1rea.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 account-based \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430\u0445 | ProHoster","og:description":"\u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:56:25+00:00","article:modified_time":"2019-10-31T18:56:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34101","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:56:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:28:34","updated":"2026-01-21 17:56:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}