Translation of Official Chia Blockchain Documentation

Target audience: technical audience familiar with blockchain, but not familiar with Proofs of Space (PoS), Proofs of Time/Verifiable Delay Functions (VDF) and Chia.

If you are new to Bitcoin/ blockchain, first read the tutorial: Bitcoin and Cryptocurrency Technologies.

Goal: The Chia Consensus algorithm is aimed at creating an environmentally friendly, safe and decentralized alternative to Proof of Work (PoW).

The Proof-of-Work (PoW) algorithm of cryptocurrencies burns a huge amount of electricity. In addition, it tends to become centralized due to the concentration of production and equipment ownership, as well as due to the concentration of cheap energy, which makes PoW inaccessible to ordinary users and vulnerable to various attacks.

The concept of Proof of stake or PoS (proof of ownership) has many forms, each of which has its pros and cons. Some common disadvantages: concentrated control of stock exchanges; concentration of delegation;
the use of checkpoints and subjectivity (the requirement to be online regularly); unavailability for ordinary users; various risks; clock synchronization, network bandwidth and other assumptions about
security.

Introduction

Decentralized consensus algorithms require Sybel stability with limited (not infinite) cryptographically verifiable resources. In previous blockchain systems, computing power and
rates were limited resources. Proof of space is an alternative that is much closer to Bitcoin’s original ideal of “one processor — one vote”, since storage capacity is used as a limited resource. For example, a person who stores 500 GB has 5 “votes”, a person who stores 100 GB has 1 “vote”, where voting means an opportunity to win and confirm a block, and not an actual vote along the chain. However, using only the
storage capacity is not safe. Another part of the cryptographic puzzle is used to protect the system: namely, a verifiable delay function, which is a cryptographic proof that real time has passed. An honest system
can be created by combining the proofs of space and time. In such a system, users store random data on their hard drives for a certain period of time, and their chances of winning Chia are proportional to the space they have allocated. In addition, such a system scales up to billions of participants, similar to a proof-of-work lottery. No funds, special equipment, registration or authorization are required to join, only a hard disk. The system is completely transparent and deterministic — anyone can effectively and objectively check which chain is canonical.

Proofs of Space

A Proof—of-space protocol is a protocol in which:

1. The verifier can send a call to the tester, and

2. The tester can demonstrate to the verifier that the tester reserves a certain amount of disk space at that particular time.

The Proof-of-Space protocol consists of three elements: tracking, testing/farming, and verification.

Figure 1: First, the provider “rafts” or allocates part of the disk space (1). Then the provider “farms”, respond to calls with Proof of space (2,3,4). The verifier verifies that the proof is valid for this
call.

Plotting is the process by which a tester, whom we call a farmer, initializes a certain amount of space. A farmer can be anyone who has at least 100 GiB to reserve on his laptop, or an enterprise that is ready to allocate a large amount of unused disk space. There is no upper limit. Plotting takes several hours or days and is performed only once. The initialized space is occupied by a file named
Raft. The raft dimensions are determined by the parameter k, where Space = 780 * k * pow (2, k — 10), with a minimum k equal to 32 (101.4 GiB). Starting with Chia 1.0, a k32 graph can be created in about six hours using a fast commodity machine and in 24 hours on a slow machine using a single processor core and several GB of memory. There are opportunities for huge acceleration. The PosSpace construction is based on BeyondHellman, but nested 6 times and contains others
heuristic elements.

The result is a raft file of size, for example, 100 GiB. The file contains seven tables with random data. There are 2^k records in each table. Each entry in table i contains two indicators for table i-1 (table above). Finally, each entry in table 1 contains a pair of integers from 0 to 2^k, called “x values”. The proof of the existence of a space is a set of 64 values of x that have a certain mathematical relationship.

In the diagram above, once the Prover initializes 100 GiB, they are ready to accept the challenge and create a proof. One of the attractive properties of this scheme is that it is not interactive: no registration or Internet connection is required to create a plot. Nothing gets into the blockchain until a reward is earned, as in PoW.

Farming is a process by which a farmer is given a number of tasks to demonstrate that he has legitimately reserved a certain amount of storage. In response to each challenge, the farmer checks his rafts, generates proofs and sends all the winning proofs to the network for verification.

Each iteration of this process is a table lookup. The search accepts a 256-bit query as input and output proofs. The farmer responds to the query by reading the values in Table 7. They point to two entries in table 6 and so on.
As a result, the farmer gets a complete tree of values-x. This requires one reading for table 7, two for table 6, four for table 5, etc. The whole process will take about 640 ms, assuming that the hard drive is slow then the search time is 10 ms. The amount of data being read is small and does not depend on the size of the raft.

Since most of the proofs generated by this process are not good enough (we will explain later) to be sent to the network for verification, we can optimize this process by checking only one branch of the tree, which gives two x values, depending on the task. Then we hash the x values generated in this way into a 256-bit string to determine if the test is good. Hashing these x values gives us a quality string, a 256-bit random value.
This is combined with the complexity and size of the raft to create the necessary repetitions. If the required repetitions are less than a certain number (we can enter the blockchain), we search for all PoSpace. It takes only about 7
disk search and read operations to find a single branch, or about 70 ms on a slow hard disk.

Figure 2: Graph file structure. 64 red x — values represent proof, 2 green x— values represent qualification.

Another optimization is to disqualify a certain part (for example, 511/512) of the eligibility rafts for each test. This is called a raft filter. For example, it is required that the hash of the task and the raft ID start with
9 zeros. This harms everyone equally (except replenishing attackers) and is therefore fair. This makes farming practically resource-free and requires a very small number of disk reads every few minutes.
Chia users have successfully used multiple PiB storages on a single Raspberry Pi. We assume that farmers still use hard drives because they are cheap and there is no reason to use SSDs since speed has nothing to do with farming. However, SSD/RAM disks can be used for faster scanning.

A raft key is a private key that is stored in a raft file. The raft ID is generated by hashing the public raft key and the public key of the pool. Creating a proof-of-space block requires signatures from both the raft key and the pool key. Therefore, the pool cannot be changed after the raft is created. In practice, a raft key is a cumulative 2/2 BLS public key between the local key stored in the raft and the key stored in the farmer’s software. For security and efficiency reasons, a farmer can run a centralized server using this key and signature scheme. The server can be connected to many harverster machines on which the rafts are stored. Farming requires a farmer’s key and a local key, but not a pool key, since the pool signature can be cached and reused for many blocks.

Verification: After farmer has successfully created a proof of the space, it can be verified by performing some hashing and comparing the x-values of the test. Remember that the proof is a list of 64 values of x, where
each value of x has lengthexcommunicated).

Farmer calculates the necessary iterations for each proof of the existence of a space. If the required iterations <span the iteration interval, the proof of space availability can be included in the blockchain, so the farmer extracts the entire proof of space from disk (which takes more time than just getting quality), creates an incomplete sub block and broadcasts it to the network. Note that the vast majority of required iterations will be too large,
since an average of 32 will meet the requirements for the entire network for each auxiliary slot. This is a random process, so a large amount of evidence can be qualified, but is very unlikely. The iterations of the pointer point are the number of iterations from the beginning of the sub-slot to the pointer point.

The infusion iterations are the number of iterations from the beginning of the sub-slot at which a block with the above quality can be included in the blockchain. This is calculated as:

infusion iterations =( signage point iterations + 3 * sp interval iterations + required iterations) % sub slot iterations

Thus, the infusion iterations will be between 3 and 4 signal points after the signal point. Farmers must submit their evidence and blocks before reaching the infusion point. The module is designed to allow overflow
into the next sub-slot if the alarm point is near the end of the sub-slot. This will be discussed in more detail later.

At the infusion point, the farmer block is combined with the VDF output of the infusion point to create a new input for the VDF from this point, that is, we pour the farmer block into the VDF. The block is fully valid only after the infusion iterations have been achieved and the VDF proof has been attached to the block.

In order for block b1 to be valid/complete, two VDF proofs must be included: one from r1 to the pointer point and one from r1 to b1. (actually more, since there are three VDF lines that will be explained later). In
Figure 5, the farmer creates at the time of placing the pointer (let’s call it B1 ’). However, B1’ is not finished yet, as it needs a VDF infusion point. After the VDF of the infusion iterations is released, it is added to B1’to form a
finished block in B1.

Figure 5: Timelords of time create evidence for both the signage point and the infusion point. But they only infuse (modify the VDF class group) for the latter. Square symbols denote infusions at which a new
VDF is started. Sp interval iterations = 3.125 million

Consider the example in Figure 5. The iterations of the sub-slot are 200 million, and the iterations with the interval sp are 3.125 million. Let’s say a farmer has only 1000 rafts.

For each of the 64 pointer points, since they are transmitted to the network every 9 seconds or every 3.125 million iterations, the farmer calculates the raft filter and sees how many rafts have passed. For each raft that has passed the filter for each pointer, the farmer calculates the necessary iterations. In this example, the farmer receives only the requested iteration <3.125 million once for the entire sub-slot (say 2.2879 million). In Figure 5, this is the 14th pointer point. The infusion iterations are calculated as:

infusion iterations = signage point iterations + 3 * sp interval iterations + required iterations

= 14*3.125M + 3 * 3.125M + 2.2879M

= 55.4129M

Realizing that they have won (at the infusion point 14), the farmer extracts the full proof of the space, sets a lock that does not necessarily include transactions, and transmits it to the network. They have a few seconds (before the infusion iterations) to reach the timelords that infuse the block, creating the infusion point VDF. With these VDF, a block can be completed and added to the blockchain.

Interval iterations Sp: defined as the lower limit (iterations of the sub-slot / 64).

Designation points: 64 intermediate points in time in the sub-slot in the test chains for which VDF are periodically released. At each point of the designation, a VDF output signal is created, which is broadcast over the network. The first pointer in the
sub-slot is the call itself. Each block has a pointer, so the proof of free space in the block must meet the criteria for that pointer.

Required iterations: a number calculated using a quality string, used to select proofs of the presence of space suitable for creating blocks. For the vast majority of proofs of the existence of space, too many iterations will be required, which cannot be included in the chain. This number is used to calculate the infusion point.

Infusion points: time point on infusion iterations from the call point toevidence of the presence of a space with a specific task and infusion iterations. At this stage, the farmer’s block joins the VDF reward chain. The infusion point of the block
is always between 3 and 4 pointer points after the pointer point of this block. Calculated as pointer point iterations + 3 * interval iterations sp + required iterations.

The delay between the designation point and the infusion point has many advantages, including protection from orphanhood and selfish farming, reducing the number of branches and the absence of VDF pauses. This delay of about 30 seconds is given so that farmers have enough time to sign without delaying the VDF slot. Good farmers sign only one notation point with each proof of space, which means that attackers cannot easily reorganize the chain.

Multiple blocks

Figure 7: Multiple blocks. Sp1 = pointers 1

As you can see in Figure 7, multiple blocks can be inserted into the same sub slot. The Chia system focuses on 32 blocks for the sub-slot and this is regulated by an algorithm of the complexity of the work. The VDF moves from the previous infusion point to the current designation point and from the previous infusion point to the current infusion point. Note that the VDF proofs required for each block, they may overlap. For example, B2 contains a proof of VDF from B1 to sp2 and from B1 to B2. B3 contains a proof from B1 to sp3 and from B2 to B3. B2 does not depend on B3 at all, but B3 depends on B2, since its VDF comes from the infusion point B2. Again, blocks are created at the points of
pointers, but there is no VDF infusion point in them; as soon as this VDF is added, the block is completed and forms part of the blockchain. There are no signatures at the infusion point; the only thing that is added to the infusion point is VDF.

Three VDF chains

If we used only one VDF (for the reward chain), including or excluding blocks would allow us to control the task for the next slot. This means that an attacker can try many different combinations
and choose the most suitable task for him. These types of attacks are called grinding attacks, and they are one of the main difficulties of moving from Proof of Work to Proof of Space or PoStake. More detailed
information is provided in the section “Attacks and counteraction measures”.

To mitigate this, the problems will be based only on the first block to be added to the slot.

Figure 8: Three VDF chains. An attacker can manipulate the results of the reward chain, but this does not affect c2 and therefore does not affect the PoSpace lottery. cc = task chain, rc = reward chain, sp = pointer point. B = block.

There’s a lot going on in this diagram. First of all, as you can see, there are 4 blocks: B1, B2, B3, B4, these are blocks created by farmers that contain all the data they point to. We assume that more than 5 blocks have been created in this sub-slot, but we don’t draw them all due to lack of space.

In addition, both the task chain and the reward chain create 64 pointer points. The blocks must include VDF point designations for both chains. The blocks should also include VDF infusion points for all three chains.

As you can see, the call chain executes VDF from the beginning of the sub-slot to the end without adding anything to it (circles — proofs of VDF, but they do not interrupt VDF). The reward chain permeates each included block. The chain in the middle is called the chain of added calls, and it starts with the first block entered for each task and continues until the end of the slot.

Slot — is a list of sub-slots that contain at least 16 blocks of the reward chain based on the task of the first sub-slot or later sub-slots. For example, we can have only 10 blocks in a sub-slot, and then 3, and then 7, which means that these three sub-slots form one slot. Usually each sub-slot is also a slot, since on average much more than 16 blocks are included. The deficit is the number of blocks that is still needed to complete the slot: this
will be described in more detail below.

At the end of the time interval, the call chain is merged with the embedded chainoops calls to generate a new c2 call, which is used to start the call chain for the next sub-slot.

The only block that affects the call chain is the first block, which in this case is B1, and only the deterministic part of B1, cc B1, which depends only on the data of the call chain. An attacker who wants to be ground cannot change the task by holding B2, B3 or any other block except the first one.

Assuming that the attacker has the fastest block (B1), he has three options: hold it, postpone it, or let it go. To find out if a new task will benefit them, they will need to complete the VDF all the way to c2. By that time, they no longer have a chance to get into the reward chain, since honest farmers sign only one block for each proof of space. Holding B1 does not give the attacker much benefit, since he must release it
before sp2 in order to include farmers in his chain. Farmers will choose the heaviest chain, which will have the most (heaviest) blocks of the reward chain.

Why do we commit to any blocks in the task chain at all? Well, if we didn’t, the attacker could look to the future with a faster VDF, since they wouldn’t need the help of honest participants
to calculate the call chain in the future. The call chain will be completely deterministic. This would give some advantage by re-plotting the graph. In addition, the task chain can be used to probabilistically prove the weight of the reward chains for simple clients without separating all the blocks of the reward chain (since the call chain depends on the “best” block in the slot, you can calculate the number of rewards of the chain blocks).

Task chain: A VDF chain based on each task for each sub-slot, which does not pour anything into the middle of each sub-slot. Calls are also used to prove the space. Pointers in this chain are used
for the SP filter.

Reward Chain: A VDF chain that contains infusions of all blocks. This chain pulls in a chain of calls and possibly a built-in call chain at the end of each sub-slot.

Filling the task chain: a VDF chain that starts with the first block inserted into the slot (which is not based on calling the previous slot, this is called a call block) and ends at the end of the slot.

Slot: a list of sub-slots that contain at least 16 blocks of the reward chain based on the task of the first sub-slot or later sub-slots. At the end of the slot, the chain of entered calls stops, the call chain pulls the result of the entered call chain, and the deficit is reset to 16.

Block: block — is a set of data entered into the reward chain, which contains: proof of the existence of a hash space for a task with fewer iterations than slot iterations, VDF sp and ip for both chains, optional IP VDF
for the embedded call chain, and address rewards. Some blocks are also transaction blocks. Maximum of 128 blocks per slot.

Transaction block: a block that has the right to create transactions together with a linked list of transactions.

Call block: the first block to be added to each slot that is not based on the call of the previous slot. The call block always has a deficit of 15, and always starts with a chain of entered calls.

Peak: the peak of the blockchain from the point of view of the node is the block with the highest weight. The weight is the sum of the complexity of the block and all its ancestors, which is similar to the height, but a shorter chain may have more weight due to the complexity of the setup.

In order for a block to be considered valid, it must provide a VDF for the call chain and reward chain and, optionally, for the embedded call chain, if present. Forcing all VDF to be enabled means that all three chains will move forward at the same speed.

Overflow blocks

In order for the farmer to create a block, their required iterations must be less than 3.125M, or the number of iterations of the sub-slot / 64, as described above. This means that there may be more infusion iterations than sub-slot iterations, and therefore the infusion
should occur in the next sub-slot.

Overflow block: a block whose infusion point is in a different sub-slot, unlike its pointer point.

The task of the current slot: with respect to a certain block B, the tasks of the current slot B include all tests starting with the first task in the slot and ending with the end of the slot (not inclusive). This is relevant because sometimes a slot
spans multiple sub-slots and hence multiple problems.

Figure 9: B4 in this diagram represents an overflow block as the infusion is in the next slot. B4 is not based on calling the current slot and thus does not reduce the deficit or create a call block. TODO:
there should be 16 diagrams, not 5.

Overflow blocks cannot exist in the first sub-slot of the epoch (since the iterations of the sub-slot change).

In addition, overflow blocks do not change the deficit unless they are based on a call to the current slot, since overflow blocks are responses to a call to the previous sub-slot. Overflow blocks are not request blocks unless they are
based on the current request slot. Note that overflow blocks rarely reduce the deficit, as the deficit will almost always decrease to zero, and a new slot will be started in each sub-slot.

Minimum requirements for the block

At least 16 task blocks of the current slot must be added to the reward chain in order for the slot to be completed.

The deficit is a number from 0 to 16, which is present at the beginning of the sub-slot. This is defined as the number of reward chain blocks that we need to add to finish the slot. It resets to 16 whenever we
start a slot (so there must be at least 16 total blocks per call chain injection). The deficit decreases for each infusion of the reward chain based on the task of the current slot.

@media screen and (min-width: 1201px) { .wzvms64e9211746f4d { display: block; } } @media screen and (min-width: 993px) and (max-width: 1200px) { .wzvms64e9211746f4d { display: block; } } @media screen and (min-width: 769px) and (max-width: 992px) { .wzvms64e9211746f4d { display: block; } } @media screen and (min-width: 768px) and (max-width: 768px) { .wzvms64e9211746f4d { display: block; } } @media screen and (max-width: 767px) { .wzvms64e9211746f4d { display: block; } }

A block with a deficit of 15 is a call block.

The normal case is when the deficit starts at 16, decreases to zero within the sub—slot and resets back to 16 when we finish the slot and start a new one. In case we fail to reduce it to 0 at the end of the slot, the call chain and the entered call chain (if any) continue and the deficit is not reset to 16. Blocks (including overflow blocks), keep subtracting from the deficit until we reach 0. When we finish sub-interval with
zero deficit, the added call chain is included in the call chain, and the deficit is reset to 16.

This requirement has been added to prevent long-range attacks and is described in detail in the section “Countermeasures”. The vast majority of sub-slots will have >= 5 blocks, so this does not greatly affect normal operation.

Figure 10: c2 — this is the end of the auxiliary slot, but not the end of the slot. c2 DOES NOT point to ic2 because the slot did not end at this sub-slot. The deficit is 2 instead of resetting to 5, and the chain of tasks continues.

Weight

The weight of the block is the sum of the complexity of this block plus all the previous blocks that are the ancestors of this block. The attached full nodes should choose the peak of the blockchain, so that the peak is the block with the heaviest weight they know about. This is the most important requirement, identical to the rule of the heaviest Bitcoin chain. Because of this rule, an attacker with less than 50% of the space and without the advantage of VDF will have problems earning more than his fair share, since he must be lucky and create more reward chain blocks than a mean chain. Moreover, farmers only form on calls that correspond to the heaviest chain.

Both the speed of the VDF and the total amount of space are important for weight, and changing them can cause a difficulty adjustment. If the amount of space increases, more than 32 blocks per slot will be created, so the difficulty should be increased. If the network VDF speed increases, more than 32 blocks are created every 10 minutes, and hence the complexity (and iteration of sub-slots) should be increased.

However, a farmer with exclusive access to a slightly faster VDF cannot easily get more reward than a farmer with a VDF with normal speed. If an attacker tries to orphan one of the blocks in the chain, having a faster VDF will not help, because there will be fewer blocks in the attacker’s chain (and therefore less weight). Farmers must sign the block on which they are building, that is). This way they can fill their reward chain and increase their weight.

The solution is to periodically (every 384 blocks, which is an average of 2 hours) pour the end of the reward chain slot into the task chain. This means that an attacker can perform a reassignment attack only for a few hours in the future. The plotting itself takes several hours, but even if an attacker can instantly reconfigure the graph, the cost of the reconfiguration attack will outweigh the benefits. We are not pouring in the current result of the reward chain, but the output of the reward chain at the end of the previous sub epoch (2 hours ago).

The cost of creating a raft includes electricity to calculate all tables, RAM required to create this raft, and fixed infrastructure costs (space, electricity, cooling, etc.). Assuming the worst-case scenario of ultrafast VDF and instant ASIC plotting, the benefits will be equivalent to the benefits of storing this slot on hard drive for several hours. It is clear that this attack is not worth it, and that storing rafts is much cheaper (analysis below).

The above explains why the interval of sub epochs should be relatively low. But why can’t we further reduce it to less than 2 hours, to further deter repeated attacks? The reason is that whenever
non-canonical data is entered into the query chain, there is an opportunity for shredding. This means that an attacker can choose to include or exclude blocks in order to control which call will be in 2 hours in the future. If this time is too short, they may gain a slight advantage in space if they do it more often.

The second purpose of sub-epochs is to act as checkpoints in a protocol similar to flyclient described below to improve the efficiency of light clients.

Easy customer verification

Easy customer support is another advantage of proof of space compared to proof of stake, since all proofs can be objectively verified cryptographically and require control of the actual resource
at a certain point in time.

For light clients who want to synchronize with the chain quickly (for example, mobile wallets), a full node can create a small proof that can convince a light client that the weight of the chain is close to some value. This is called weight proof. Naively, a lightweight client can download each block and all the necessary proofs and verify them, but with so many blocks it will require a lot of bandwidth and CPU.

A more efficient method is based on a protocol similar to Flyclient [4]. The node (tester) sends all the summaries of the sub epoch from the branching point, which include the complexity reset, to the light client. There is only one block for every 384 blocks, so it can only reach a few MB of data. The node also deterministically selects several sub epochs based on the request of the last block. Sub-epochs can be chosen proportionally to the difficulty during
this sub epoch. For the selected sub epoch, the light client loads one of the blocks of the call chain (which make up approximately 1/32 of all blocks) and calculates the average infusion iterations of all call blocks in this sub epoch. Based on this
time, an easy client can extrapolate how many blocks the reward chain contains. For example, if all the call blocks occur with very small iterations (close to the beginning of the slot), there are probably a lot of blocks in this slot. And on the contrary, if the iterations are close to the middle of the slot, there is probably only one block per slot. This allows a light client to load only 1/32 blocks into each slot, but at the same time get a good estimate of the total weight.

In addition, for a light client, it is necessary to fully load the last few sub epochs. This adds a small amount of data, but does not allow the attacker to create small branches at the end of the chain. The main difference between this
protocol and flyclient is that the blocks are not tied to the use of Merkle trees, but instead a lightweight client loads the entire hash list of sub-epochs from genesis, ensuring that the requested sub-epochs are included in the chain.Another difference is that whole sections are loaded, not individual blocks.

It is necessary to conduct additional analysis of how many sub epochs should be loaded, and what are the boundaries of what weight proof implies.

Pooling

Pooling in Chia is designed to be extremely simple and more decentralized than a pool in Bitcoin/Ethereum. In Chia, the public key of the pool is embedded in the rafts to prevent the theft of rewards from the pool to farmers participating in more than one pool. Farmer uploads the address toula along with his signature. Farmer periodically sends partial data to prove a space that has less than T iterations, where T is chosen by the pool.

When a farmer wins a block, they submit the farmer’s signature and the pool’s signature for review. Transaction fees along with block rewards go to the farmer, and block rewards go to the pool. The reason for giving a portion of the reward to the farmer is not to encourage attacks when one pool attacks another by “combining” them, but without actually presenting proof of victory. This is an attack that can disable another pool.

This is easier because the pool does not need to do anything except publish its signature on the website once, collect partial data and make periodic payments. It is more decentralized because blocks are created by farmers, so large centralized pools have little control over the network, and this increases the resistance to censorship of transactions.

The second more complex pool protocol will allow you to specify a single-element smart contract in which the pool address will be stored. Then the rafts will include a hash of the smart contract puzzle, allowing farmers to switch pools at any time with a delay. The disadvantage of this unification protocol is that an intra-chain transaction is required to start farming, and therefore it is not entirely better than the first unification protocol.

Timelord algorithm

The timelord keeps track of the current peak, which includes the infusion unit at a certain height, and the pointer points, starting from the peak and further. The timelord can receive new blocks to fill, new peaks (blocks that are already filled)
or new pointer points.

How does the timelord decide for which tasks it is necessary to create time proofs, given the limited number of available processors? While ASICs are likely to evolve in the future, currently the fastest class group VDF implementations are on general purpose hardware, as it seems that class group VDF is complicated for FPGA. Moreover, even after the development of the ASIC, it is important that any user with a CPU can be a timelord in order to
provide a backup option in case the ASIC timelord fails or becomes malicious, etc.

In general, timelords work with the heaviest chain. They create time proofs on the pointers and broadcast them to the network as they reach them. They also introduce blocks as often as they can. When a timelord receives a
filled block that has more weight than the current peak, it immediately switches to it.

Timelords also run three VDF chains in parallel. Therefore, at least 3 fast CPU cores are needed to effectively promote the blockchain. To create proofs at an effective speed, additional CPU cores will be required, but they should not be so fast.

If a timelord receives a call with less weight than their current peak, it ignores it.

If the timelord receives a call point later in the current chain, it is safest to ignore it. The reason is that when switching to a point located further in the future, the timelord may skip the infusion of blocks and, thus,
loses valid blocks.

If a timelord receives an infusion block that is late (we have already reached the call point at which the block should have been filled), we ignore this, since switching to it will allow attackers to hold the blocks [TODO
expand]. Therefore, the main operation of the timelord involves saving the cache of future blocks for implementation, broadcasting control points when they are reached, and injecting blocks when we reach their control points.

If a timelord receives a call with the same weight as the current peak, he chooses the unfinished block that they saw first (that is, the block that has not yet been filled), as opposed to choosing the filled block (peak) that they saw first. This also prevents block delays.

Related attacks and countermeasures

51% (46%) attack:

51% of attacks involve the creation of an alternative chain that eventually reaches a higher weight than the genuine chain and forces users to reorganize. The classic ranged attack, which is also present in proof-of-work systems, is 51% of attacks. In 51% of attacks, an attacker who owns 51% of the network space creates an alternative chain and eventually reaches it. There are two main differences between Chia consensus and Proof of Work: the first is that an attacker can expand and farm simultaneously in many chains. Secondly, if the attacker has the fastest VDF, he can get an additional advantage /
acceleration in space.

Extension of many chains

If an attacker creates his own private chainIf you sign a farmer in N blocks, he will be able to cancel or change the order of any transaction in these N blocks. It is potentially possible to use
fraud proofs, but they were not chosen because they allow other attacks and complicate behavior.

Instead, the solution is to just wait longer. After 32 blocks

(approximately 10 minutes), the assumption that at least one farmer

abides by the protocol, rather than double signing, is reasonable.

If 54% do not collude (assuming 46% attack resistance), the probability of cancellation after 32 blocks is 1.8 * 10-13 = 0.00000000000018. In addition, this attack can be detected, so it is not easy to carry out.

Each user can choose his own threshold for which he accepts the transaction/block as final. For example, in cases where the total network space suddenly drops, users can be more careful and not consider transactions final if there is another fork, for example, due to network separation.

Freeing transaction blocks from transaction fees

Transaction blocks differ from non-transaction blocks because they contain transaction fees. They may exceed the block reward. At the time of writing (November 2020), at the peak of the HYPE, we see 2 rewards for an eth block with 8 commissions per block. In Chia, this will be more extreme, since not every block contains transactions. This leads to attacks when the farmer who took 2nd place ignores the 1st place in an attempt to win a transaction block. If the 2nd block
comes less than 30 seconds after the 1st, they do not indicate the previous block, and thus the 2nd place cannot discard the 1st. The third place could drop both, but no one will follow this chain, since it is shorter.

However, if there are no blocks within 30 seconds after the 1st block, the 2nd can discard the 1st, but they will have to convince the next block to farm in their alternative chain. An easier attack would be if the attacker controlled both the 2nd and the 3rd, in which case he could ignore the first and at the same time be longer. These lone attacks do not allow the attacker to steal the rewards, but allow the attacker to slightly reduce the complexity. Since they are very situational in nature and require a lot of space, an attempt of such an attack is likely to cause more harm to the network than a potential benefit for the attacker.

Dropping metrics

According to the Chia consensus, two competing blocks at about the same time can be included in the block chain in parallel, without knowing about each other. (Although there can be a maximum of one block). Since all transaction blocks are also
blocks, they are both included in the chain, resulting in a chain with a higher weight. This means that the percentage of discarded indicators in Chia will be almost zero if we assume a low network latency. If the network delay exceeds the infusion delay (30-40 seconds), then the discarded block is almost guaranteed, so this is more of a step-by-step function. This contrasts with Nakamoto-PoW, in which the percentage of data discarding is high if there is a delay in the network, and gradually decreases as the network condition improves, but never reaches zero.

Security

The security is similar to other Nakamoto consensus algorithms such as Bitcoin. There is no guaranteed finality, but the more confirmations a transaction has, the safer it is. A transaction requires a certain number of confirmations so that the recipient assumes that it cannot be changed according to <46% (* vdf benefits). Since farmers can theoretically sign multiple blocks at the same height, more confirmations should be used in Chia than in Bitcoin. However, at a rate of 32 blocks in 10 minutes, 6 confirmations in bitcoins are equivalent to 192 in chia, which is more than enough to be considered safe. As long as one of these 192 farmers behaves well (without a double signature), this transaction will not be canceled.

It is worth noting that 54% of genuine farming space is not required, but 54% do not collude. Profit-seeking farmers get very little from rejecting the protocol.

There is an additional assumption that at least one fast timelord must be connected to a non-colluding part of the network, and that the attacker’s timelord is not much faster.

Survivability

The survivability of the Chia consensus system is one of its greatest strengths. Like Bitcoin, the Chia system continues to evolve even when most of the space is disconnected. However, unlike bitcoin, the system does not slow down much when this happens, since not all blocks are transaction blocks. Thus, transaction throughput will not drop much if many participants disconnect. It will continue even if only 1 farmer is online,
although there will be a lot of empty slots, since a transaction block can only be created if it is below the sub-slot iteration threshold.

Of course, in the case of long-term network separation, the consequences are such that one chain must be chosen, so in this case there may be large reorganizations. However, the network chooses a heavier chain, as does PoW.

Comparison with consensus BFT algorithms

The proof of free space can also be used as a Sybil resilience mechanism to launch the Byzantine Consensus system (k-agreement). Filecoin and many proof-of-stake systems use aspects of the Byzantine consensus.

Pros and cons of using the Chia Nakamoto Consensus versus the Byzantine Consensus, which vary from algorithm to algorithm:

• Much easier
• No registration required
• No scalability requirements (scales to millions of farmers)
• More resistance to censorship. As long as a small part of the farm space is not censored, eventually you can get into the blockchain
• No survivability requirements, potentially less network assumptions
• Completely objective (the node can compare chain 1 and chain 2 and immediately find out which one is heavier). There is no need for control points with consensus ⅔
• Best support for light clients
• Without finality, only probability
• It is necessary to wait longer for confirmation of the transaction
• Less block time agreed and less transaction throughput

Comparison with Nakamoto PoW

• Different resources. PoSpace is ASIC-resistant, so anyone can participate in farming. More decentralized.
• Easy association of farming. Other cryptocurrencies can use the same format, and everyone can share the space. Probably, the upper one will be the only safe one, since farmers can attack more
  small ones.
• Minimal power consumption, since only a few nodes are running VDF, and they are not parallelized. Very low marginal cost for mining.
• More consistent transaction block time (once every ~1 minute).
• Less susceptible to selfish mining attacks.
• There are fewer discarded indicators and ramifications, since the blocks can be turned on in parallel.
• Still progressing at the same rate with decreasing space, since only 1/16 of the block includes transactions. The Nakamoto PoW consensus is slowing down.
• The disadvantage of more potential attackers (large companies). General-purpose equipment, so attackers can switch between farming, attacking and using for data storage.
• Acceleration of VDF can give an advantage in space to the attacker of the network.
• Greater complexity due to sub slots and VDF, potentially more cryptographic assumptions

Comparison with Proof of Ownership (PoS)

This consensus algorithm can also be used to prove ownership share when farmers’ space is replaced by stake holders who own coins in the system. The advantage will be the ability to reduce (remove
the share of people), and farmers will have “their own interest”, but there are some concerns if proof of ownership is used. (+ means the advantage of using the space compared to the ownership share).

• An attacker can transfer his share to someone else, but forks the chain right before transferring his share. In this alternative chain, the attacker still has his entire share and, therefore, can promote the chain. The “nothing is at stake” problem in PoStake is different from PoSpace, because creating PoSpace requires a physical resource (hard disk space), and creating PoS requires only a key.
• The attacker can guarantee his share by betting his rewards (the rich get richer), since the total number of coins is limited.
• There may be situations when an attacker can use many different ways to transfer a bet. Perhaps this can be mitigated if it takes a long period of time before the bid becomes active.
• Registration is required, you cannot participate in the proof of ownership of the bet until you register. This reduces privacy and scalability (how many people can bid).
• Higher barrier to entry: collateral deposits and slashing make it difficult for small users to participate. Slashing can be a huge risk for network members. Centralized custodians lead to a less
  distributed set of participants.
• Some assumptions [11] are required to perform an easy client synchronization to confirm the share.
• Interest: With PoStake, consensus can reduce the proportion of people, and also requires some investment in the system (price dependence). In the dockdue to the ownership share, hard drives can be used for other purposes, and there is no way to “reduce” people’s equipment.

Original article: https://servergate.ru/articles/chia-blockchain-instruktsiya-po-ekspluatatsii/