I know I know. There are a lot of crypto projects, there are a lot of consensuses: based on labor and ownership, gold, oil, baked pies (there is one, yes, yes). What else do we need from one? This is what 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, is there a place to "be" such a consensus or is it not needed for nothing?
There are not many letters further, so if you just want to write “fu, as much as you can 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 cat.
PS I'm not the author of the technology, I can't vouch for the complete transfer of the essence, so I'll be glad for comments with amendments, if any.
Evolution from synchronous to asynchronous consensuses
Nodes are selected using a deterministic process (the same as used in DHT, such as bittorrent) that dynamically adjusts the responsibilities of the nodes to "facilitate" validation or, more clearly, to reach consensus. We select groups of 3 nodes and run consensus rounds in parallel so that one node can be a facilitator in multiple blocks. This allows us to process transactions asynchronously, which essentially means we have multiple blockchains running at the same time. The process is like a web formed by many threads, as opposed to knots forming a single chain over time. Asynchronous or parallel processing is the backbone of scalable programming because it makes use of all the resources of a computer, speeding up overall computing. This network is called a directed acyclic graph or DAG in computer science.
Linear blockchain channel width vs DAG multiplicative effect where we have multiple parallel blockchains.
Geometric implementation of a 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 state, forming a "surface plane" across the data in the form of triangles with connections. The protocol then uses triangles to "stitch" an optimal surface that does not contain redundant or inconsistent data and has the smallest possible triangles. Algorithmically, this is analogous to the "minimum cut" of the graph, and mathematically, it is analogous to the derivative or optimization function (of which the function finds the shortest path that it can cross over the surface). This shortcut is equivalent to optimally storing data (transactions) in a DAG. Conflicting triangular “tiles” to keep the event surface flat and free of conflicts.
Geometric implementation of conflict detection/handling. A conflicting block creates an additional surface tile. We remove the extra surface tile to maintain a flat (= conflict-free) event surface.
Reputation Based Consensus
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 that includes transitive relationships, or relationships that a node has with other nodes, when assigning a global score. "You are as good as your company." The end result is a "skew" or gradient based on transitive trust or reputation across all nodes in the $DAG or regular channel. It can be thought of as a brush or cheese grater that erases over a “surface plane” and chooses which “triangular tiles” to erase and which to keep. This is how the conflict logic actually removes the “triangular tiles”.
A DAG with a conflicting tile going through a "curved" space, which is a cheese grater-like gradient, and is about to remove or "erase" the conflicting tile.
Partial/Full Node Scaling
In network theory, the optimal distribution is generally known as "no scaling", which can be described as a hierarchical arrangement with large central nodes controlling 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.
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 seen as a “decentralized smart contract platform”. Instead of a central network doing all the logic and processing all the data from the application, Constellation coordinates the application data with "regular channels", which can be thought of as a TV station broadcasting all the data from the standard system. Each state channel can implement its own validation logic to solve the problem of oracles through end-to-end authentication of data producers and transitive check of composite state systems. Established channel networks provide concurrent support for applications, accelerating adoption time, which in a smart contract network is limited by traditional synchronous consensus.
Two regular channels that are "compatible" through the $DAG network. They can interact or be interpreted as both are "integrated" with $DAG by deploying $DAG + Channel hybrid nodes.
The reason it's called Hylochain is because our application support approach used the Recursion Schemes functional programming model to create the MapReduce interface. In particular, the recursion schemes Hylomorphism (Hylomorphic) and Metamorphism (Metamorphic) can be integrated to create verifiable requests and streaming connections through regular 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 compatible with existing big data technology.
Hylomorphic and Metamorphic regular channels for contrast. In the metamorphic state, data from two regular channels is sent to a block in the metachannel. In Gilo we take the previous state of a channel and use it to query (ask a specific question) two other channels and then store the result of the query in a block.
Tokenomics and its relationship with Hylochain
Once a regular channel has been created, it can be integrated into the $DAG channel, but using the ACI or Application Chain Interface. This interface is just a JSON object with configuration information and a public key associated with the channel itself. The reason we associate the public key with the regular channel is to create a broker mechanism for the regular channel data. When a regular channel is deployed, developers themselves configure how payments from the $DAG network are distributed between nodes and operators.
Flow for purchasing 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.
Source: habr.com