{"id":36425,"date":"2019-10-31T22:11:34","date_gmt":"2019-10-31T19:11:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/konsensus-na-reputatsii-nody-nuzhen-li\/"},"modified":"2019-10-31T22:11:34","modified_gmt":"2019-10-31T19:11:34","slug":"konsensus-na-reputatsii-nody-nuzhen-li","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","title":{"rendered":"Consenso na reputa\u00e7\u00e3o do n\u00f3. Precisa mesmo?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sei que h\u00e1 muitos projetos de criptomoedas, com v\u00e1rias formas de consenso: baseado em trabalho e propriedade, ouro, petr\u00f3leo, at\u00e9 bolinhos assados (sim, isso existe). O que precisamos de mais um? Isso \u00e9 o que proponho discutir ap\u00f3s a leitura da tradu\u00e7\u00e3o da documenta\u00e7\u00e3o t\u00e9cnica 'simplificada' do projeto *Constela\u00e7\u00e3o* (Constela\u00e7\u00e3o<\/a><\/noindex>). Claro, isso n\u00e3o \u00e9 uma descri\u00e7\u00e3o completa do algoritmo, mas estou curioso pela opini\u00e3o da comunidade Habr, ser\u00e1 que esse tipo de consenso pode existir ou \u00e9 desnecess\u00e1rio?<\/p>\n

<\/p>\n

N\u00e3o h\u00e1 muitas letras a seguir, ent\u00e3o, se voc\u00ea simplesmente quer escrever 'uf, quanto mais sobre criptomoedas', por favor, contenha-se. Se voc\u00ea est\u00e1 interessado em novos desenvolvimentos na \u00e1rea de sistemas distribu\u00eddos e tem algo a compartilhar nos coment\u00e1rios, sinta-se \u00e0 vontade para prosseguir.<\/p>\n

<\/p>\n

P.S. N\u00e3o sou o autor da tecnologia, n\u00e3o posso garantir a completa transmiss\u00e3o do conceito, ent\u00e3o ficarei feliz com coment\u00e1rios e corre\u00e7\u00f5es, caso existam.<\/em><\/p>\n

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

A evolu\u00e7\u00e3o de consensos s\u00edncronos para ass\u00edncronos<\/h3>\n

<\/p>\n

Os n\u00f3s s\u00e3o escolhidos usando um processo determin\u00edstico (o mesmo usado no DHT, por exemplo, bittorrent), o qual ajusta dinamicamente as responsabilidades dos n\u00f3s para \"facilitar\" a valida\u00e7\u00e3o ou, de forma mais compreens\u00edvel, para alcan\u00e7ar um consenso. Escolhemos grupos de 3 n\u00f3s e realizamos rodadas de consenso em paralelo, permitindo que um n\u00f3 possa ser facilitador em v\u00e1rios blocos. Isso nos permite processar transa\u00e7\u00f5es de forma ass\u00edncrona, o que, em ess\u00eancia, significa que estamos formando v\u00e1rios blockchains ao mesmo tempo. O processo \u00e9 semelhante a uma teia formada por m\u00faltiplos fios, ao contr\u00e1rio de n\u00f3s que formam uma \u00fanica cadeia ao longo do tempo. O processamento ass\u00edncrono ou paralelo \u00e9 a base da programa\u00e7\u00e3o escal\u00e1vel, pois permite utilizar todos os recursos do computador, acelerando os c\u00e1lculos gerais. Essa rede \u00e9 chamada de grafo ac\u00edclico direcionado ou DAG em ci\u00eancia da computa\u00e7\u00e3o.<\/p>\n

<\/p>\n

\"Consenso
\nLargura do canal do blockchain linear contra o efeito multiplicativo do DAG, onde temos v\u00e1rios blockchains paralelos. <\/em><\/p>\n

<\/p>\n

\"Consenso
\nImplementa\u00e7\u00e3o geom\u00e9trica do blockchain linear contra o DAG. Pontos pretos s\u00e3o blocos, pontos brancos s\u00e3o n\u00f3s.<\/em><\/p>\n

<\/p>\n

Usamos 3 n\u00f3s em cada rodada de consenso, pois isso nos proporciona alguns processos matem\u00e1ticos interessantes para raciocinar sobre o estado, formando uma \"superf\u00edcie\" atrav\u00e9s dos dados na forma de tri\u00e2ngulos interconectados. Em seguida, o protocolo utiliza esses tri\u00e2ngulos para \"costurar\" a superf\u00edcie \u00f3tima, que n\u00e3o cont\u00e9m dados redundantes ou contradit\u00f3rios e possui o menor n\u00famero poss\u00edvel de tri\u00e2ngulos. Algoritmicamente, isso \u00e9 an\u00e1logo ao \"corte m\u00ednimo\" de um grafo e, matematicamente, a uma derivada ou fun\u00e7\u00e3o de otimiza\u00e7\u00e3o (da qual a fun\u00e7\u00e3o encontra o caminho mais curto que pode cruzar pela superf\u00edcie). Esse caminho mais curto \u00e9 equivalente ao armazenamento \u00f3timo de dados (transa\u00e7\u00f5es) em um grupo de disponibilidade de bancos de dados. Os tri\u00e2ngulos \"tijolos\" conflitantes garantem que a superf\u00edcie do evento seja lisa e sem conflitos.<\/p>\n

<\/p>\n

\"Consenso
\nImplementa\u00e7\u00e3o geom\u00e9trica de detec\u00e7\u00e3o \/ processamento de conflitos. Um bloco conflitante cria um tijolo adicional na superf\u00edcie. Removemos o tijolo de superf\u00edcie adicional para manter uma superf\u00edcie plana (= sem conflitos) de eventos. <\/em><\/p>\n

<\/p>\n

Consenso baseado em reputa\u00e7\u00e3o<\/h3>\n

<\/p>\n

Em um sistema de reputa\u00e7\u00e3o p2p descentralizado \u00f3timo, cada n\u00f3 deve ser capaz de determinar independentemente sua confian\u00e7a em outros n\u00f3s. Nosso sistema utiliza um modelo especial que inclui rela\u00e7\u00f5es transitivas ou rela\u00e7\u00f5es que o n\u00f3 possui com outros n\u00f3s ao atribuir uma avalia\u00e7\u00e3o global. \"Voc\u00ea \u00e9 t\u00e3o bom quanto a sua empresa\". O resultado final \u00e9 uma \"distor\u00e7\u00e3o\" ou gradiente baseado na confian\u00e7a ou reputa\u00e7\u00e3o transitiva em todos os n\u00f3s em um $DAG ou canal de estado. Isso pode ser visto como um ralador ou uma escova que apaga a superf\u00edcie da \"plano\" e decide quais \"tijolos triangulares\" apagar e quais deixar. \u00c9 assim que a l\u00f3gica do conflito realmente remove os \"tijolos triangulares\".<\/p>\n

<\/p>\n

\"Consenso
\nDAG com um tijolo conflitante, passando por um espa\u00e7o \"distorcido\", que \u00e9 um gradiente semelhante a um ralador, e se prepara para remover ou \"apagar\" o tijolo conflitante.<\/em><\/p>\n

<\/p>\n

Escalonamento parcial \/ completo do n\u00f3<\/h3>\n

<\/p>\n

Na teoria das redes, o que geralmente se conhece como distribui\u00e7\u00e3o ideal \u00e9 chamada de \"sem escalonamento\", que pode ser descrita como uma disposi\u00e7\u00e3o hier\u00e1rquica com grandes n\u00f3s centrais controlando muitos n\u00f3s perif\u00e9ricos menores. Essa distribui\u00e7\u00e3o \u00e9 vista na natureza e, acima de tudo, na internet. A Constellation utiliza essa arquitetura para \"escalonar\", ou aumentar a largura de banda ou a capacidade do nosso Grafo.<\/p>\n

<\/p>\n

\"Consenso
\nEfeito da divis\u00e3o hier\u00e1rquica. Podemos adicionar mais n\u00f3s, aumentando a largura da capacidade.<\/em><\/p>\n

<\/p>\n

Hylochain \u2014 Suporte a aplicativos baseados em canais.<\/h3>\n

<\/p>\n

Nossa abordagem para o suporte a aplicativos pode ser vista como uma \"plataforma descentralizada de contratos inteligentes\". Em vez de uma rede central realizando toda a l\u00f3gica e processando todos os dados do aplicativo, a Constellation coordena os dados do aplicativo com \"canais dedicados\", que podem ser vistos como uma esta\u00e7\u00e3o de televis\u00e3o transmitindo todos os dados do sistema dedicado. Cada canal dedicado pode implementar sua pr\u00f3pria l\u00f3gica de verifica\u00e7\u00e3o, permitindo resolver o problema dos or\u00e1culos atrav\u00e9s da verifica\u00e7\u00e3o cruzada da autenticidade dos produtores de dados e da verifica\u00e7\u00e3o transitiva dos sistemas dedicados compostos. As redes de canais dedicados oferecem suporte paralelo a aplicativos, acelerando o tempo de aceita\u00e7\u00e3o, que em uma rede com contratos inteligentes \u00e9 limitado pelo consenso s\u00edncrono tradicional.<\/p>\n

<\/p>\n

\"Consenso
\nDois canais dedicados que s\u00e3o \"compat\u00edveis\" atrav\u00e9s da rede $DAG. Eles podem interagir ou ser interpretados, uma vez que ambos est\u00e3o \"integrados\" com $DAG atrav\u00e9s do desdobramento de n\u00f3s h\u00edbridos $DAG + Canal.<\/em><\/p>\n

<\/p>\n

A raz\u00e3o pela qual se chama Hylochain \u00e9 que nossa abordagem para o suporte a aplicativos utilizou um modelo funcional de programa\u00e7\u00e3o, Recursion Schemes, para criar uma interface MapReduce. Em particular, os esquemas de recurs\u00e3o Hylomorphism e Metamorphism podem ser integrados para criar consultas verific\u00e1veis e conex\u00f5es de fluxo atrav\u00e9s de canais padr\u00e3o, verificando tipos de dados alg\u00e9bricos da mesma forma que se verificam op-codes para contratos inteligentes. O resultado final \u00e9 uma interface funcional MapReduce familiar para engenheiros de dados e compat\u00edvel com a tecnologia existente de big data.<\/p>\n

<\/p>\n

\"Consenso
\nCanais padr\u00e3o Hylomorphic e Metamorphic para contraste. No estado metam\u00f3rfico, os dados de dois canais padr\u00e3o s\u00e3o enviados para um bloco no metacanal. No Hilo, pegamos o estado anterior do canal e o usamos para consultar (fazer uma pergunta espec\u00edfica) outros dois canais, e ent\u00e3o salvamos o resultado da consulta em um bloco.<\/em><\/p>\n

<\/p>\n

Tokenomia e sua rela\u00e7\u00e3o com o Hylochain<\/h3>\n

<\/p>\n

Quando um canal padr\u00e3o \u00e9 criado, ele pode ser integrado ao canal $DAG, mas utilizando a interface ACI ou Application Chain Interface. Essa interface \u00e9 simplesmente um objeto JSON com informa\u00e7\u00f5es de configura\u00e7\u00e3o e uma chave p\u00fablica associada ao pr\u00f3prio canal. A raz\u00e3o pela qual vinculamos a chave p\u00fablica ao canal padr\u00e3o \u00e9 para criar um mecanismo de corretagem para os dados do canal padr\u00e3o. Quando o canal padr\u00e3o \u00e9 implantado, os desenvolvedores configuram como os pagamentos da rede $DAG s\u00e3o distribu\u00eddos entre n\u00f3s e operadores.<\/p>\n

<\/p>\n

\"Consenso
\nFluxo para a compra de acesso a informa\u00e7\u00f5es ou modifica\u00e7\u00e3o de informa\u00e7\u00f5es. A solicita\u00e7\u00e3o \u00e9 enviada ao $DAG, os fundos s\u00e3o enviados para a conta do canal, o resultado \u00e9 enviado ao comprador e a soma de verifica\u00e7\u00e3o da transa\u00e7\u00e3o \u00e9 enviada para a rede $DAG, que ent\u00e3o desbloqueia os fundos para o canal padr\u00e3o.<\/em><\/p>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0417\u043d\u0430\u044e-\u0437\u043d\u0430\u044e. \u041a\u0440\u0438\u043f\u0442\u043e\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0442\u044c\u043c\u0430, \u0435\u0441\u0442\u044c \u043a\u0443\u0447\u0430 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u043e\u0432: \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0442\u0440\u0443\u0434\u0430 \u0438 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u044f, \u0437\u043e\u043b\u043e\u0442\u0430, \u043d\u0435\u0444\u0442\u0438, \u0432\u044b\u043f\u0435\u0447\u0435\u043d\u043d\u044b\u0445 \u043f\u0438\u0440\u043e\u0436\u043a\u043e\u0432 (\u0435\u0441\u0442\u044c \u0438 \u0442\u0430\u043a\u043e\u0439, \u0434\u0430-\u0434\u0430). \u0427\u0442\u043e \u043d\u0430\u043c \u0435\u0449\u0451 \u043e\u0442 \u043e\u0434\u043d\u043e\u0433\u043e? \u042d\u0442\u043e \u0438 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0431\u0441\u0443\u0434\u0438\u0442\u044c \u043f\u043e\u0441\u043b\u0435 \u043f\u0440\u043e\u0447\u0442\u0435\u043d\u0438\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 «\u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u043d\u043e\u0439» \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 *\u0421\u043e\u0437\u0432\u0435\u0437\u0434\u0438\u0435 (Constellation). \u041a\u043e\u043d\u0435\u0447\u043d\u043e, \u044d\u0442\u043e \u043d\u0435 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u0430, \u043d\u043e \u043c\u043d\u0435 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u043c\u043d\u0435\u043d\u0438\u0435 \u043a\u043e\u043c\u044c\u044e\u043d\u0438\u0442\u0438 \u0445\u0430\u0431\u0440\u0430, \u0438\u043c\u0435\u0435\u0442 \u043b\u0438 \u043c\u0435\u0441\u0442\u043e «\u0431\u044b\u0442\u044c» \u0442\u0430\u043a\u043e\u043c\u0443 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u0443 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27262,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36425","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Consenso na reputa\u00e7\u00e3o do n\u00f3. \u00c9 necess\u00e1rio? | ProHoster","description":"Eu sei, eu sei. Existem muitos projetos de criptomoeda, com uma infinidade de consensos: baseado em trabalho e posse, ouro, petr\u00f3leo, tortas assadas (sim, existe um assim, sim). O que precisamos de mais um?","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","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\u041a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441 \u043d\u0430 \u0440\u0435\u043f\u0443\u0442\u0430\u0446\u0438\u0438 \u043d\u043e\u0434\u044b. \u041d\u0443\u0436\u0435\u043d \u043b\u0438? | ProHoster","og:description":"\u0417\u043d\u0430\u044e-\u0437\u043d\u0430\u044e. \u041a\u0440\u0438\u043f\u0442\u043e\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0442\u044c\u043c\u0430, \u0435\u0441\u0442\u044c \u043a\u0443\u0447\u0430 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u043e\u0432: \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0442\u0440\u0443\u0434\u0430 \u0438 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u044f, \u0437\u043e\u043b\u043e\u0442\u0430, \u043d\u0435\u0444\u0442\u0438, \u0432\u044b\u043f\u0435\u0447\u0435\u043d\u043d\u044b\u0445 \u043f\u0438\u0440\u043e\u0436\u043a\u043e\u0432 (\u0435\u0441\u0442\u044c \u0438 \u0442\u0430\u043a\u043e\u0439, \u0434\u0430-\u0434\u0430). \u0427\u0442\u043e \u043d\u0430\u043c \u0435\u0449\u0451 \u043e\u0442 \u043e\u0434\u043d\u043e\u0433\u043e?","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","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-31T19:11:34+00:00","article:modified_time":"2019-10-31T19:11:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36425","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-22 03:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:35","updated":"2026-01-22 03:15:20","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\/36425","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=36425"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36425\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/27262"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=36425"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=36425"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=36425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}