Consensus on the reputation of the node. Do I need?

I know I know. Crypto projects of darkness, there is a bunch of consensus: on the basis of labor and possession, gold, oil, baked pies (there is such, yes, yes). What else do we have from one? This and I propose to discuss after reading the translation of the "lightweight" technical documentation of the project * Constellation. Of course, this is not a complete description of the algorithm, but I’m interested in the opinion of the Habr community, does such a consensus have a “be” or is it not needed for nothing?

There are not many more letters, so if you just want to write "fu, how much is possible about the crypt", then please refrain. If you are interested in new developments in the field of distributed systems and have something to share in the comments, then I ask under the cat.

PS I am not the author of the technology, I can not vouch for the full transfer of the essence, so I will be glad to comment with the amendments, if any.

Evolution from synchronous consensus to asynchronous

Nodes are selected using a deterministic process (the same as used in DHT, for example, bittorrent), which dynamically adjusts the responsibilities of nodes to “facilitate” validation or, more understandably, to reach consensus. We select groups of 3 nodes and perform consensus rounds in parallel so that one node can be a facilitator in several blocks. This allows us to process transactions asynchronously, which, in essence, means that we are simultaneously forming several blockchains. The process is similar to a web made up of multiple threads, in contrast to the nodes that form one chain over time. Asynchronous or parallel processing is the basis of scalable programming, since it allows you to use all the computer resources, speeding up general calculations. This network is called a directed acyclic graph or DAG in computer science.

The width of the linear blockchain channel versus the multiplicative effect of DAG, where we have several parallel blockchains.

Geometric implementation of linear blockchain against DAG. Black dots are blocks, white dots are nodes

We use 3 nodes in each round of consensus, because it gives us some interesting mathematical processes for reasoning about the state, forming a “surface plane” across the data in the form of triangles with links. The protocol then uses triangles to “merge” an optimal surface that does not contain redundant or contradictory data and has the smallest possible triangles. Algorithmically, this is analogous to the “minimal cut” of a graph, and mathematically, a derivative or optimization function (of which the function finds the shortest path that it can cross over the surface). This shortest path is equivalent to optimal storage of data (transactions) in the database availability group. Conflicting triangular “tiles” so that the surface of the event is smooth and free from conflict.

Geometric implementation of the detection / handling of conflicts. The conflicting block creates an additional tile surface. We remove the tile of the additional surface in order to maintain a flat (= conflict-free) surface of the events.

Consensus based on reputation

In an optimal decentralized p2p reputation system, each node should be able to independently determine its trust in other nodes. Our system uses a special model, which includes transitive relations or relationships that a node has with other nodes, when assigning a global estimate. “You are as good as your company.” The end result is a “distortion” or gradient based on transitive trust or reputation at all nodes in a $ DAG or state channel. This can be seen as a brush or cheese grater, which blurs over the “surface plane” and chooses which “triangular tiles” to erase and which ones to leave. This is how conflict logic actually removes “triangular tiles.”

A DAG with conflicting tiles passing through a “curved” space, which is a gradient similar to a cheese grater, and is about to remove or “erase” the conflicting tile.

Partial / full node scaling

In network theory, as a rule, the optimal distribution is known as “without scaling”, which can be described as a hierarchical arrangement with large central nodes that control many smaller peripheral nodes. This distribution is visible in nature and, above all, on the Internet. Constellation uses this architecture to “scale”, or increase the bandwidth or width of our graph.

The effect of hierarchical partitioning. We can add more nodes by increasing the bandwidth.

Hylochain - Channel Based Application Support

Our approach to application support can be viewed as a “decentralized platform of smart contracts.” Instead of a central network that performs all the logic and processes all the data from the application, Constellation coordinates the application data with the “regular channels”, which can be viewed as a television station broadcasting all the data from the standard system. Each regular channel can implement its own verification logic, which allows to solve the problem of oracles through the end-to-end authentication of data producers and transitive verification of composite state systems. Regular channel networks provide parallel application support, accelerating adoption time, which in the network with smart contracts is limited by traditional synchronous consensus.

Two regular channels that are “compatible” through the $ DAG network. They can interact or be interpreted as both of them are “integrated” with $ DAG by expanding the hybrid nodes of the $ DAG + Channel.

The reason why it is called Hylochain is that our approach to application support used the functional programming model Recursion Schemes to create the MapReduce interface. In particular, Hylomorphism (Guilomorphic) and Metamorphism (Metamorphic) recursion schemes can be integrated to create scanned queries and streaming connections through standard channels by checking algebraic data types in the same way as op-codes for smart contracts are checked. The end result is a functional MapReduce interface that is familiar to data engineers and is compatible with existing big data technology.

Hylomorphic and Metamorphic regular channels for contrast. In the metamorphic state, data from two regular channels are sent to the block in the meta channel. In Gilo, we take the previous channel status and use it to query (ask a specific question) two other channels, and then save the result of the query in a block.

Tokenomics and its relationship with Hylochain

When a regular channel is created, it can be integrated into the $ DAG channel, but using the ACI interface or the Application Chain Interface. This interface is simply a JSON object with configuration information and a public key associated with the channel itself. The reason why we associate a public key with a regular channel is to create a brokerage mechanism for regular channel data. When the regular channel is deployed, the developers configure themselves how payments from the $ DAG network are distributed between nodes and operators.

Feed for the purchase of access to information or modification of information. The request is sent to $ DAG, the funds are sent to the channel account, the result is sent to the buyer, and the transaction checksum is sent to the $ DAG network, which then unlocks the funds for the regular channel.