{"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\/en\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","title":{"rendered":"Consensus on node reputation. Is it necessary?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I know, I know. There are a multitude of crypto projects, with numerous consensus methods: based on work and ownership, gold, oil, baked pies (yes, that exists, indeed). What do we need from another one? I suggest we discuss this after reading the translation of the 'lightweight' technical documentation of the *Constellation project (Constellation<\/a><\/noindex>). Of course, this is not a complete description of the algorithm, but I am curious about the community's opinion on whether such a consensus has a place or is it unnecessary?<\/p>\n

<\/p>\n

There aren't many more letters, so if you just want to write 'ugh, how much more about crypto,' please refrain. If you're interested in new developments in the field of distributed systems and have something to share in the comments, please feel free to continue reading.<\/p>\n

<\/p>\n

P.S. I'm not the author of the technology, so I can't guarantee a full transfer of its essence, so I would appreciate comments with corrections, if there are any.<\/em><\/p>\n

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

Evolution from synchronous consensus to asynchronous<\/h3>\n

<\/p>\n

Nodes are selected using a deterministic process (the same one that is used in DHTs, like BitTorrent), which dynamically adjusts node responsibilities for 'lighter' validation or, more clearly, for achieving consensus. We select groups of 3 nodes and perform consensus rounds in parallel, allowing one node to facilitate several blocks. This lets us process transactions asynchronously, which essentially means we have multiple blockchains forming simultaneously. The process resembles a web formed by numerous threads, as opposed to nodes forming a single chain over time. Asynchronous or parallel processing is the foundation of scalable programming, as it allows the use of all computer resources, speeding up overall computations. This network is called a directed acyclic graph or DAG in computer science.<\/p>\n

<\/p>\n

\"Consensus
\nThe bandwidth of a linear blockchain compared to the multiplicative effect of DAG, where we have several parallel blockchains. <\/em><\/p>\n

<\/p>\n

\"Consensus
\nGeometric representation of linear blockchain versus DAG. Black dots are blocks, white dots are nodes.<\/em><\/p>\n

<\/p>\n

We use 3 nodes in each consensus round because it provides us with interesting mathematical processes for reasoning about state, forming a 'surface plane' across data in the shape of triangles with connections. The protocol then uses these triangles to 'stitch' together an optimal surface that contains no redundant or conflicting data and has the minimum number of triangles possible. Algorithmically, this is analogous to a 'minimum cut' of a graph, and mathematically, it pertains to derivatives or optimization functions (from which the function finds the shortest path it can traverse across a surface). This shortest path is equivalent to the optimal storage of data (transactions) within a database availability group. Conflicting triangular 'tiles' ensure that the event surface remains flat and conflict-free.<\/p>\n

<\/p>\n

\"Consensus
\nGeometric implementation of conflict detection \/ resolution. A conflicting block creates an additional surface tile. We remove the extra surface tile in order to maintain a flat (= conflict-free) event surface. <\/em><\/p>\n

<\/p>\n

Reputation-based consensus<\/h3>\n

<\/p>\n

In an optimal decentralized p2p reputation system, each node must be able to independently determine its trust in other nodes. Our system employs a special model that includes transitive relationships or the relationships a node has with other nodes when assigning a global score. 'You are only as good as your company.' The end result is a 'distortion' or gradient based on transitive trust or reputation across all nodes in the $DAG or main channel. This can be viewed as a grater or cheese shredder that erases parts of the 'surface plane' and decides which 'triangular tiles' to erase and which to keep. This is how conflict logic actually removes 'triangular tiles.'<\/p>\n

<\/p>\n

\"Consensus
\nDAG with a conflicting tile passing through the 'distorted' space, which resembles a grid or cheese grater, and is set to remove or 'erase' the conflicting tile.<\/em><\/p>\n

<\/p>\n

Partial\/complete node scaling<\/h3>\n

<\/p>\n

In network theory, optimal distribution is generally known as 'without scaling,' which can be described as a hierarchical arrangement with large central nodes managing many smaller peripheral nodes. This distribution is evident in nature and, primarily, on the Internet. Constellation uses this architecture for 'scaling,' or increasing the bandwidth or capacity of our Graph.<\/p>\n

<\/p>\n

\"Consensus
\nEffect of hierarchical decomposition. We can add more nodes, thereby increasing the bandwidth.<\/em><\/p>\n

<\/p>\n

Hylochain \u2014 Support for channel-based applications.<\/h3>\n

<\/p>\n

Our approach to application support can be seen as a 'decentralized smart contract platform.' Instead of having a central network that executes all logic and processes all data from the application, Constellation coordinates application data with 'native channels,' which can be viewed as a television station broadcasting all data from a native system. Each native channel can implement its own verification logic, addressing the oracle problem through end-to-end authentication of data producers and transitive verification of composite native systems. Native channel networks provide parallel application support, reducing the time to decision, which in a smart contract network is limited by traditional synchronous consensus.<\/p>\n

<\/p>\n

\"Consensus
\nTwo native channels that are 'compatible' through the $DAG network. They can interact or be interpreted as both are 'integrated' with the $DAG by deploying hybrid nodes $DAG + Channel.<\/em><\/p>\n

<\/p>\n

The reason it is called Hylochain is that our approach to application support used the functional programming model of Recursion Schemes to create a MapReduce interface. Specifically, Hylomorphic and Metamorphic recursion schemes can be integrated to create verifiable queries and streaming connections over standard channels by checking algebraic data types just as opcodes are checked for smart contracts. The end result is a functional MapReduce interface that data engineers are familiar with and compatible with existing big data technology.<\/p>\n

<\/p>\n

\"Consensus
\nHylomorphic and Metamorphic standard channels for contrast. In the metamorphic state, data from two standard channels is sent to a block in the metachannel. In Hilo, we take the previous state of the channel and use it to query (ask a specific question) two other channels, and then save the query result in the block.<\/em><\/p>\n

<\/p>\n

Tokenomics and its connection to Hylochain<\/h3>\n

<\/p>\n

Once the standard channel is created, it can be integrated into the $DAG channel, but using the Application Chain Interface (ACI). This interface is simply a JSON object containing configuration information and the public key associated with the channel itself. The reason we link the public key to the standard channel is to create a brokerage mechanism for the data of the standard channel. When the standard channel is deployed, developers configure how payments from the $DAG network are distributed among nodes and operators.<\/p>\n

<\/p>\n

\"Consensus
\nA stream for purchasing access to information or modifying information. The request is sent to the $DAG, funds are sent to the channel\u2019s account, the result is sent to the buyer, and the transaction hash is sent to the $DAG network, which then unlocks the funds for the standard channel.<\/em><\/p>\n

Source: 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\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\udd47Consensus based on node reputation. Is it needed? | ProHoster","description":"I know, I know. There are a plethora of crypto projects, with numerous consensus types: based on labor and ownership, gold, oil, baked goods (yes, that exists, indeed). What more do we need from another one?","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/36425","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=36425"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/36425\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/27262"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=36425"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=36425"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=36425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}