cool hit counter Technical details on DAG blockchain project SPECTRE_Intefrankly

Technical details on DAG blockchain project SPECTRE

DAG Labs, the blockchain startup that previously released the DAG blockchain project SPECTRE, officially announced the technical details of its latest scaling protocol PHANTOM in February, revealing that it will be smart contract compatible and enable linear alignment of blocks on the chain. According to the Thunderbird AI Financial Review, at the TeCoin Technology Exchange conference hosted by Berkeley Blockchain, Yonatan Sompolinsky, chief scientist at DAG Labs and co-author of the GHOST protocol, gave the audience a detailed overview of the specific technical challenges encountered by the DAG application blockchain network, and explained the SPRECTRE project's solutions and underlying parameter tuning for scalability and security of blockchain transactions.

The first thing that needs to be understood is that blockchain is something new. If you have a system to improve the performance of the extended blockchain, applying a DAG (Directed Acyclic Graph) on the SPECTRE project can do this very well.

As the picture shows, two questions are first elicited. First of all, what are the current transactions in the blockchain like? You can imagine queuing up for business at a bank, where users wait one after another in a sequence, and only when the previous user completes the transaction can the next user start to act, ensuring consistency and follow-through across the blockchain in this way. When there are too many users needing to do business crowding into the bank, the transaction jam becomes worse and worse.

The DAG is designed to achieve such performance optimization for the sake of speeding up transaction processing rates and saving the time spent by users while waiting for transactions. For this influx of users waiting to transact, whether they are holding cash or doing card business, the DAG network no longer sorts them into rows and rows of waiting, but speeds up to do their business for them. If a transaction conflict occurs, the DAG network records it first, and then disposes of any conflicts that arise after all users' transactions have been processed, speeding up the transaction rate for the entire batch of users as a whole. The DAG network replaces the blockchain in the traditional sorting way by such an arrangement, thus promoting it as a daily routine for the DAG application blockchain.

Usually, on a technical level, in a distributed system, developers follow the "CAP" theorem for development and maintenance, which are the above-mentioned consistency, availability, and isolation, respectively. In previous blockchains, the first factor that needed attention was consistency, the distributed ledger needed to be consistent, the information about the transactions after being on the chain needed to be consistent, the creation of a block, the information contained in it had to be consistent with the previous history, and the whole system was designed to try to maintain this feature. This is why there is a queue at the bank waiting for information to be synced, as seen in the previous image. The DAG blockchain network, on the other hand, is more focused on availability, ensuring that every user can complete transactions on top of this network.

Technical challenges of blockchain for DAG applications: chaotic block generation leads to conflicting transactions

In the present, Bitcoin is trading at about 3-7 transactions per second, so when will it get to over a thousand transactions per second? What modifications to existing blockchain systems would be required to achieve such transaction performance? We need to start with some understanding of the technical limitations of blockchain. First, let's take a look at what the transaction flow per second looks like in a simplified diagram of a blockchain system containing ten blocks. As shown in the diagram, the information stored in each block is directed to the next connected block that is generated, and each branch is directed to the original creation block, making the information traceable and thus forming a "fork" of the tree.

In the network of DAG application blockchain, each block has adjacent blocks to refer to, and focusing on one of the blocks, it can be found that it can be connected to other blocks to open up, reflecting a high degree of availability, but at the same time, after the blocks open up to each other, the mining behavior will be challenged due to the frequent occurrence that may lead to more hard forks. Also more serious: after the blocks no longer follow a sequence, there will be a significant increase in the incidence of conflicting transactions in each block, such as the double spending problem.

Specifically, to address these issues, two consensus principles have been developed in the mining protocol in the DAG network: rule 1, each new block added must be created with the entirety of past blocks as a reference; rule 2, all block-generated transaction information must be published in the first place.

What are the biggest drawbacks exposed by such a DAG combined with blockchain system? The regulation of transactions is a big issue. As shown in the figure, for example, when a miner wants to mine after a user has made a transaction in a block, its transaction information is quickly published to the entire blockchain, and many miners are quick to beg for the mining result, and conflicts accumulate very quickly. So the main challenge is that in such a DAG network graph, after generating blocks by referring to previous blocks, how to ensure the consistency of the information contained in the newly generated blocks, and the consequent large number of conflicts generated in the transactions?

It is also a challenge to distinguish between catching attacks launched against this blockchain network, such as the double flower problem mentioned earlier. When a transaction occurs and the chances of two miners mining the result at the same time are high, who gets the reward for the transaction fee? Also, how do you calculate the proof of workload for different miners? Also the storage problem stands out as very serious, and if over a thousand transactions per second are achieved, the amount of data generated for transaction information will be huge. There are many other consequential issues, but the most important and primary one that needs to be addressed is that of consistency.

How can solutions be developed for these problems? Based on the previously described dilemma of DAG combined with blockchain network applications, it is demonstrated that it is only an application model, which itself is a data structure framework rather than an off-the-shelf solution, and there are good and bad cases of specific DAG applications to blockchain networks. So how to make a protocol for a blockchain network with a high performance DAG application? Firstly in a complex blockchain environment where blocks are arranged in a chain, branch-like structure, it is difficult to find the blocks hidden among them that belong to the attacker, but it can interfere with generating the correct blocks and can slow down the entire blockchain environment. So a good protocol for a DAG application blockchain needs to be easy to distinguish to find these attack blocks in the first place.

The first principle of the protocol for building a DAG application blockchain is to command each block to be arranged in a given order as a way to get consistency. As shown earlier for these blocks, it is only when the order of arrangement is given that the user understands which is the Genesis block, which follows the previous block, and which block's transactions are prioritized to enable traceability and maintain data consistency.

From there we move from the DAG application blockchain model to a specific solution case study. Behind the SPECTRE protocol, there is a design of information voting mechanism considerations. Try to imagine voting for the best of many outstanding athletes on a blockchain, which means that users need to pick a winner and discard all the others that are left. It's like being inside a community where people who vote tell each other which is their favorite athlete to vote for. We call this the "single winner vote system".

However, within this system, only one winner is selected by the largest number of votes, and it is not possible to rank all the athletes in the running. In a multi-winner voting system, users can vote on all candidates to be ranked. The resulting system can integrate information about users' preferences for all voting objects, extending and supplementing the amount of this information.

Returning to the issue of screening attack blocks, as shown in the figure, we can view blocks as competing with each other for existence, but for this chain in red that is independent of the main chain, the existence of this independent chain is not known even after sharing all information between blocks, so there is a small probability that this hidden lone chain may become a longer one in the process of generating blocks and thus seize control of the entire blockchain network.

SPECTRE voting mechanism to identify attacks

To prevent this, in SPECTRE's DAG blockchain network protocol, we use a mechanism of all-user voting to form the architecture of the entire network. Specifically for the order of generation of each block, users can decide the order of generation of block X and block Y on block Z. Miners have no voting rights and only need to follow such an order for mining, going by the logical process of algorithmically deriving the calculation of block Y to be generated after block X, preventing them from dominating and controlling the generation of the whole blockchain network for profit. When a specific voting mechanism is specified to generate blocks, the votes on each block are pooled into a majority opinion of the users, and this determines the order of generation for the entire blockchain network.

The newly produced block in the figure, which originates from the result of a joint vote between block group X and block group Y. According to the majority principle, the new block is generated immediately after the X block chain. The blue Z-block cluster only carries information about the X-block without reference to the Y-block chain, which means that for the blue Z-block, the Y-block chain is in a hidden state and there is no way to know about its existence.

This is a subjective view, and similarly, for the red Z block group connected after the Y block chain, there is no way to know about the existence of the X block group since there is no reference to the X block information. So, when this yellow block in the figure is generated, it can be known by referring to the adjacent blocks that it is a block belonging to X. By analogy, the entire blockchain network architecture is determined by eventually deriving the attribution of all blocks based on the voting mechanism. It can be seen that the Y blockchain does not refer to any trusted block node to achieve double flower attack discrimination against this blockchain network.

So we can conclude that compared with other DAG application blockchain networks mentioned at the beginning, SPECTRE's network architecture design security has been greatly improved, the reason is that under such a mechanism, after normal users generate blocks, it is impossible for attackers' blocks to account for the majority of blocks to launch an attack, and trusted blocks are always better than questionable suspicious blocks, eliminating the possibility of 51% attacks while achieving extremely high availability of the whole network. Such a design ensures that, with ten or even over a hundred blocks being generated a second, all blocks, including trusted blocks on the network, will not be scattered and connected to each other for lack of sequencing instructions, leading to the kinds of confusion-inducing security issues mentioned at the beginning.

Users are on the chain, when should they publish their transactions? In blocks, there is a delay of hundreds of seconds in announcing transactions to the entire network, which is then quickly broadcast to the public network, and if a transaction conflict occurs due to the double spend phenomenon, an infinite delay can occur under the voting mechanism. The reason why block group X is better than block group Y to become the main chain is the mechanism of all users voting to generate blocks, while if X and Y publish transactions at the same time, the system will probably not be able to make a decision with instant judgment. However, this will only hurt the attacker itself and cannot cause damage to the system. As a trusted block, it is generated based on the sequence carrying the information of the previous block and will not be connected to adjacent blocks, so there is no double spend problem.

Block bandwidth tuning ensures transaction performance

The entire blockchain network exhibits high scalability while ensuring security. So what are the limitations of achieving performance of over a thousand transactions per second on this network? The primary limitation is in the bandwidth. If over a hundred blocks are generated per second without a limit, the accumulation of too many block generation will exceed the carrying capacity and there is no way to solve any problem. Rather, the minimum bandwidth for different types of blocks needs to be determined depending on the setting of the target transaction volume. As an example, to achieve a transaction performance of 10,000 TPS, SPECTRE adjusts the bandwidth of five MB per second to generate ten blocks of size zero.5 MB per second.

There is a trade-off between scalability and the pursuit of decentralization between the bandwidth limit of blocks and the frequency of transactions: reducing the bandwidth of blocks allows more users to participate and facilitates the trend towards decentralization, but causes the frequency of transactions to suffer, and how to maintain a balance between them is a key consideration. Try to imagine that if the minimum bandwidth of the block is adjusted to two MB per second, the amount of transactions that can be processed per second is far less than 10,000 and the system may be swamped with congested transactions. Therefore, when designing a blockchain network, the bandwidth of the blocks and the settings of the underlying parameters cannot be changed arbitrarily out of the consideration of simply increasing the participation of more users, which will affect the operation of the entire blockchain network and the performance of the target transactions.

Another limitation is the issue of data storage. If one MB of information is generated per second, eighty-six GB of data will be generated per day. On the SPECTRE blockchain network, it is not possible to store all the data on the chain so that it is a reasonable choice. Therefore, we propose a data storage solution called "rolling checkpoints". At the end of each day's mining effort, faced with hundreds of brand new blocks generated, SPECTRE stores information about the previously occurring transaction data in a fixed centralized node for the entire blockchain network to check and update periodically.

This requires the user to submit trust in the system, believing that no errors were previously missed, or tampered with, in their stored information. In this case, the central node storing the data needs to verify the authenticity of the demo storage data to ensure error-free. Again, we have to find keep finding better ways to strike a balance between decentralized data storage and system performance.

A layered framework in DAG networks: mutual isolation of the application and data layers

From the current point of view, miners are very important factors in the governance of a hierarchically structured blockchain network and can influence protocol updates, incentives and also feel the validity of transactions. Assuming that storage services for containers now need to be purchased, workers can only be called upon to provide cargo handling and storage services by means of financial incentives. Similar to it, miners on the data layer of the blockchain obey the consensus mechanism of proof of workload and move on to the next mining job only after verifying that the reward paid is correct. Without sound incentives and rewards and penalties, miners will potentially dispose of users' transaction information at will, possibly broadcasting announcements on the public network, or processing correctly occurring transactions as invalid.

In the layered structure of SPECTRE, the application layer and the data layer are isolated from each other. On the data layer, miners are only responsible for collecting transaction data to ensure that it represents validly occurring transactions to form a traceable and untamperable shared database. In the application layer, the distributed ledger needs to be generated to reflect the data and explain the ins and outs of each transaction, and since different applications follow different transaction logic, different transaction systems such as smart contracts have to be accessed in the DAG network to implement the execution and eventually generate transaction data to verify the results of the miners' work.

1、From User Data to Test Cases A Note on Voice Testing Improvement
2、nginx example How to prevent large images from filling up bandwidth
4、The 101st China Knitting and Cotton Fair2019 Shanghai China Needle Fair
5、WeChat applets that matter feature summary

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送