## **Mining**

Ergo mining is based on [Autolykos](https://docs.ergoplatform.com/mining/autolykos/), an ASIC-resistant Proof of Work algorithm written in Scala.

**Start Mining**

[Join a pool
](https://docs.ergoplatform.com/mining/setup/join/) :
Join a pool and start mining today.

[Solo Mining](https://docs.ergoplatform.com/mining/setup/solo/): Only recommended if you have 1%+ net hash

**Getting Started**

[Wallets](https://docs.ergoplatform.com/dev/wallets/) : Get your wallet setup

[Autolykos](https://docs.ergoplatform.com/mining/autolykos/): Read about the Autolykos Algorithm, Governance, Storage Rent and more.

[SmartPools and Subpooling](https://docs.ergoplatform.com/mining/smartpools/) : Mine in localised subpools.

**Community spaces**

[Discord](https://discord.gg/Q86PNMwRsu) : Join us on Discord.

[Telegram](https://t.me/ergo_mining) : Join us on Telegram.

[Reddit](https://reddit.com/r/erg_miners) : Join us on Reddit.

[Mining Guide](https://ergonaut.space/en/Mining) 


**Utilities**

[Mining Breakeven Price Calculator](https://babygrenade.github.io/ergo-profit-calc/)

[Difficulty and epoch monitor](http://cds.oette.info/ergo_diff.htm)

[Ergo Explorer](https://explorer.ergoplatform.com/)



Mining

Miners

## **Autolykos**

Ergo mining is based on Autolykos, a fairly launched efficient ASIC-resistant Proof of Work algorithm.

[Start Mining
](https://docs.ergoplatform.com/mining/setup/join/) : Getting setup with a mining pool.

[Algorithm](https://docs.ergoplatform.com/mining/algorithm/) : Dive into the Autolykos Algorithm.

[Governance](https://docs.ergoplatform.com/mining/governance/) : PoW To The People

[Storage Rent](https://docs.ergoplatform.com/mining/rent/) : On-chain garbage collection that reduces the problem of blockchain bloat

[Difficulty Adjustment](https://docs.ergoplatform.com/mining/difficulty/) : See how the mining difficulty is calculated.

[Emission](https://docs.ergoplatform.com/mining/emission/) : The Ergo emission schedule

Autolykos

## **Ergo Emission Schedule**

Ergo's journey, which began in 2017, saw the successful launch of its mainnet in July 2019.

**Total Supply and Allocation**

Ergo's total supply is capped at **97,739,925 ERGs** and distributed as follows:

**Genesis State Inclusions:** Includes 1 ERG for proof-of-no-premine and 4,330,791.5 ERGs for the[ Foundation Treasury.](https://explorer.ergoplatform.com/en/addresses/4L1ktFSzm3SH1UioDuUf5hyaraHird4D2dEACwQ1qHGjSKtA6KaNvSzRCZXZGf9jkfNAEC1SrYaZmCuvb2BKiXk5zW9xuvrXFT7FdNe2KqbymiZvo5UQLAm5jQY8ZBRhTZ4AFtZa1UF5nd4aofwPiL7YkJuyiL5hDHMZL1ZnyL746tHmRYMjAhCgE7d698dRhkdSeVy)


**Miner Rewards:** 93,409,132 ERGs, designated for 2,080,800 blocks, as per the emission schedule ([Miner Reward Box](https://explorer.ergoplatform.com/en/addresses/2Z4YBkDsDvQj8BX7xiySFewjitqp2ge9c99jfes2whbtKitZTxdBYqbrVZUvZvKv6aqn9by4kp3LE1c26LCyosFnVnm6b6U1JYvWpYmL2ZnixJbXLjWAWuBThV1D6dLpqZJYQHYDznJCk49g5TUiS4q8khpag2aNmHwREV7JSsypHdHLgJT7MGaw51aJfNubyzSKxZ4AJXFS27EfXwyCLzW1K6GVqwkJtCoPvrcLqmqwacAWJPkmh78nke9H4oT88XmSbRt2n9aWZjosiZCafZ4osUDxmZcc5QVEeTWn8drSraY3eFKe8Mu9MSCcVU)).

The Treasury's funds were governed by a smart contract that released ERGs gradually over the first 2.5 years, without exceeding 10% of the circulating supply.

**Ergo Foundation**

The Ergo Foundation is dedicated to protocol development, ecosystem growth, promoting the use of Ergo for social good, supporting decentralized infrastructure, and upholding privacy rights. The Foundation's Treasury, which received 4.43% of the total ERG emission, is utilized to support a wide range of initiatives. For more detailed information, refer to the [transparency report](https://docs.ergoplatform.com/ergo-foundation-2022/).

**Mining and Emission Duration**

Ergo's block reward decreases by 3 ERG per block every quarter until 2026 and stabilizes at 3 ERG per block thereafter. The mining process is projected to continue until around 2045, extended from the original 2027 timeline with the passage of the [EIP27](https://docs.ergoplatform.com/mining/standards/eip27/) soft-fork. For a visual overview, see the emission schedule on [ergo.watch](https://ergo.watch/emission).


## **Unique Aspects of Ergo's Emission**

**Proof of No Premine**

Ergo includes Bitcoin and Ethereum block hashes and headlines from The Guardian, Vedomosti, and Xinhua in its pre-genesis state for verification purposes. This is detailed in the [mainnet.conf file](https://github.com/ergoplatform/ergo/blob/1935c95560a30b19cdb52c1a291e8a389ba63c97/src/main/resources/mainnet.conf#L11).


**Verification Process**

Ergo's emission logic underwent rigorous verification using the Stainless formal verification tool, ensuring accuracy and validity. Details can be found in [this code section](https://github.com/ScorexFoundation/sigmastate-interpreter/pull/580/files#diff-18d3c92c2086c9ddd9b462191b55cf5e8438a29b0e786c6ab541f7def8330808).

**No Out-of-Thin-Air Emission**

Ergo's "coinbase" transaction, the first transaction in each block, does not create new tokens out of thin air. This policy ensures traceability of every coin or token from a legitimate source, enhancing the integrity and scarcity of Ergo's native currency, and contributing to economic stability.



Ergo Emission Schedule

## **Ergo-First-Year-Token (EFYT)**

EFYT was systematically airdropped and then listed on the Waves DEX in May 2017, with an initial supply of 100,000 tokens. This launch aimed to build an early community around the platform and raise capital for development and marketing before launching the mainnet.

## Distribution and Allocation
**Total Supply**

The maximum supply of EFYT is capped at 1,970,945.0, mirroring 10% of Ergo's first-year token emission which corresponds to the amount of ERGs the Ergo Foundation recieved in this same period.

[EFYT token distribution on Pywaves.](http://pywaves.org/assets/725Yv9oceWsB4GsYwyy4A52kEwyVrL5avubkeChSnL46)

[EFYT market and price tracking on livecoinwatch.](https://www.livecoinwatch.com/price/ErgoFirstYearToken-EFYT)


**Redemption Process**

EFYT holders could exchange their tokens for ERG at a 1:1 rate via the Waves gateway. This option was available until July 1st, 2021, with unclaimed EFYT tokens totaling 188,330 by the end of the offer. Overall, the Treasury exchanged 1,782,615 ERG for EFYT.

**Compensation and Expenses**

Initially, EFYT was used for team and external contributor compensation, and operational costs like server and integration expenses. In 2018, approximately 150,000 EFYT was allocated for compensation for developers.

**Investors**

The project avoided a traditional ICO, opting for minimal private investment and focusing on accredited angel investors to align with regulatory standards. In total, 500,000 EFYT was sold to [three private investors.
](https://t.me/ergoplatform/3354)

## Resources

**Additional information and resources are included:**

[Kushti discussing EFYT in 2018.
](https://t.me/ergoplatform/3354)

The team's hot wallet: [3P3yFxqAeFGnTDvCjeCEyMnMZevJxurKZne.](https://wavesexplorer.com/assets/3P3yFxqAeFGnTDvCjeCEyMnMZevJxurKZne)
Background on EFYT: [The Ergo Emission Schedule (2019)](https://ergoplatform.org/en/blog/2019_05_20-curve/).




Ergo-First-Year-Token (EFYT)

## **Understanding Difficulty Adjustment in Ergo**

Difficulty adjustment is a core mechanism in proof-of-work cryptocurrencies like Ergo. It ensures that blocks are added to the blockchain at a stable rate, aiming for a 120-second block interval in Ergo. This feature is critical for maintaining network security and fairness. Here we explore how Ergo's Autolykos protocol has been adapted over time to offer a robust difficulty adjustment mechanism.

## Autolykos Protocol: The Foundation for Difficulty Adjustment
Ergo's difficulty adjustment is grounded in its Autolykos protocol. Initially, Autolykos employed the linear least squares method for this purpose. This technique relied on historical data from the previous eight epochs (equivalent to 8,192 blocks) to predict future difficulty levels. Compared to Bitcoin's mechanism, it achieved a significantly lower error rate—1.9% as opposed to Bitcoin's 9.1%, as explained in this paper

**Challenges and Vulnerabilities with the Original Difficulty Adjustment**

While effective, the original Autolykos algorithm was vulnerable to rapid changes in hash rate. For example, during periods of super-linear growth in hash rate, such as the ETH merge, the system would experience severe difficulty spikes. On the flip side, periods of low activity could result in considerable drops in difficulty.

**EIP37: Refining Autolykos for Better Responsiveness**

To address these vulnerabilities while retaining the strengths of the Autolykos protocol, Ergo introduced [Ergo Improvement Proposal 37 (EIP37](https://docs.ergoplatform.com/mining/standards/eip37/)). This update made the difficulty adjustment mechanism more responsive by considering a shorter and more recent history of blocks. EIP37 didn't replace Autolykos but refined it, making it more resilient against sudden hash rate changes and adversarial disruptions.

With the adoption of EIP37, the Autolykos-based difficulty adjustment in Ergo has become more robust and adaptive. It can now better handle sudden and substantial fluctuations in the network's hash rate, making the network more secure and maintaining the 120-second block interval more consistently.

**The Future of Difficulty Adjustment** 

The need for performance statistics on the current Difficulty Adjustment Algorithm (DAA) has been expressed. Such data would allow for a comparison with other popular options in backtesting. The efforts of the development team in refining the DAA, both initially and currently, are acknowledged.

It's important to note that backtesting only shows how the DAA will perform against a static adversary. However, in reality, adversaries are adaptive, and all known DAAs are essentially of the same kind. A breakthrough would involve using an adaptive algorithm, although no specific ideas are currently available in this regard.

Finally, the question of whether any other DAA with the same epoch length would perform better has been raised. If not, studying the effects of a shorter epoch length could be a worthwhile topic of investigation.

## The Rationale Behind a 2-Minute Block Interval 

Ergo's 2-minute target block interval is a carefully chosen parameter that offers a security cushion against a variety of potential issues and threats that could affect a peer-to-peer cryptocurrency network, especially one that supports complex smart contracts. This article elaborates on the reasons behind this design choice and its benefits.

**Providing Buffers in Network Activities**

One of the often-overlooked advantages of the 2-minute block time is that it has provided essential buffers across various activities in the network. Specifically, it aids in decision-making processes related to the verifier's dilemma. In the world of blockchain mining, there is often a trade-off between adding more transactions to a new block and starting the mining process for that block as soon as possible. The 2-minute block time affords miners ample time to make these crucial decisions, thus enhancing the overall stability and integrity of the network.

**Resistance to Timewarp Attacks**

A shorter block interval could make the network more susceptible to Timewarp attacks. This type of attack involves a malicious miner manipulating the timestamps of the blocks they mine, tricking the network into believing that more time has passed than actually has. Consequently, the network may lower the mining difficulty, making it easier for the attacker to mine subsequent blocks rapidly. The 2-minute block interval adds a layer of security against such difficulty manipulation attacks.

**Minimizing the Risk of Orphaned Blocks**

Another benefit of a 2-minute interval is the reduction in the likelihood of orphaned blocks. These occur when two miners solve a block almost simultaneously, causing the network to accept one and leave the other as an 'orphan.' Orphaned blocks are not only a waste of computational resources but also pose a risk for double-spending attacks. The longer block time allows for more robust propagation and verification processes, thereby minimizing the risks associated with orphaned blocks.

**Efficiency in Epoch Length**

Ergo's epoch length, which is approximately 4.2 hours assuming a normal block rate, is considerably shorter than Bitcoin's two-week epoch. This allows for quicker adjustments in network parameters and provides an efficient mechanism for maintaining network health.

**Introduction to 'Weak Blocks'**

Another important layer of scalability and efficiency comes from the concept of "weak blocks," a feature aimed at improving both the transaction throughput (TPS) and the speed of transaction confirmations. Weak blocks act as block candidates with lower difficulty levels than standard blocks. They are propagated through the network along with new transactions, effectively optimizing network bandwidth usage. Weak blocks are not only beneficial for faster transaction confirmations but also hold the potential to facilitate quicker and more efficient sidechain operations. For a detailed explanation and further reading on how weak blocks contribute to Ergo's scalability, please refer to .[./uses/sidechains/weak-blocks.md.](https://docs.ergoplatform.com/uses/sidechains/weak-blocks/)



Understanding Difficulty Adjustment in Ergo

## **Solution Verification**

Solution verification is the process of validating that a miner has solved the mathematical puzzle required to add a block to the blockchain network. In cryptocurrency mining, miners compete to solve a cryptographic puzzle. The first miner to solve the puzzle is rewarded with new coins and fees from the transactions included in the block. Other nodes on the network must then verify the solution to ensure its validity. Solution verification is an important aspect of cryptocurrency mining, as it ensures the integrity of the blockchain network and prevents fraudulent transactions.

Test vectors are necessary for solution verification in cryptocurrency mining because they provide a standardized set of inputs and outputs to test the verification process's accuracy and correctness.

When miners solve a mining puzzle, they produce a solution that is essentially a hash value that meets a specific set of criteria. The network must verify this solution before it can be accepted as valid and included in the blockchain.

Test vectors provide a consistent and reliable way to test the verification process and ensure it works correctly. Any errors or inconsistencies can be identified and corrected by comparing the expected output from the test vector with the actual output produced by the verification process. This helps to ensure the mining process's integrity and the blockchain's security.

`Test Vectors - Ergo:
credit: Wolf9466#9466 on Discord

Height = 569806 (0x8B1CE)
Item count = 67108864 (0x4000000)
Prehash Item KAT:

Item index 0          : 0x00596fe417902d8fe61763deb06286d3bf787f3c8ea2cc3063724dd307993caa
Item index 4          : 0x00832cba40f67d525e9c449f17f46e3bfcdb663427d4289e35bc8e04b0c97765
Item index 255        : 0x003f44309d54120e5d41b36a245fea4098948f7e8c5c052247922b74a6c8e7b9
Item index 67108863    : 0x000701c3dd5db987aab0bb57f6e89ea9dbdc1dd88ffcac698bfde407d95063ce


Message = 0x9b8cb36a9b738fa3678521d00c938631e1a192bc1919f004d2cbabdaa33835b4
Nonce = 0x5d340003e9c460dc

Blake #1: 0xbd54dc777dc062c63b2f8cdd4d56f4f57b64d648420f62ef0e6f3935b0046fc99e7ea07b167ccadeaf2cd396504477697f5123e72887f61333358b5edbd5aa66

Blake #2: 0x6dbc710c2fb6e975d93af456686617b97595a0cec9dd22d57b8a7176d3f470b175eccfc1f97cecc13207fb68358c608930e5d7cfcdd0b3a4da8b9acb508e3248

Result = 0x0c3b54f29c8ac1a407f83cd09f3d61bc32996a3d58a7d9fe9fe0e0a08572e367f96b164cc3254ce5379622e007de97c76b1232030d899e0da83bc82e00000000
`

Solution Verification

## **Autolykos Line-by-line**

Autolykos is a proof-of-work (PoW) algorithm utilized in blockchain mining. It's based on the principles outlined in the Equihash paper, which itself is an exploration of the [generalized birthday problem](https://www.researchgate.net/publication/316904748_Equihash_Asymmetric_Proof-of-Work_Based_on_the_Generalized_Birthday_Problem). This guide provides an in-depth explanation of the Autolykos algorithm by breaking down its pseudocode and underlying mechanics.

## The Core Mechanism: An Overview
In essence, miners are tasked with finding k (=32) elements from a set of N elements. The chosen elements should yield a sum that, when hashed, has a hash value lower than a target value. The first miner to solve this puzzle can add the next block to the blockchain.


## Autolykos Block Mining Pseudocode

![](https://storage.googleapis.com/ergo-cms-media/Screenshot_2022_06_01_at_23_41_49_b2cdf73a2a/Screenshot_2022_06_01_at_23_41_49_b2cdf73a2a.png)

**Pre-Requisites: The Cyclic Group**

Before diving into the block mining procedure, it's important to understand that Autolykos requires:

a very large cyclic group G

of prime order q

with fixed generator g

And identity element e.

This prime group returns integers in Z/qZ during the Blake2b256-based hashing function.

Example cyclic group with generator z, identity element 1, order 6

![](https://storage.googleapis.com/ergo-cms-media/unnamed_1_44d138eaaf/unnamed_1_44d138eaaf.png)

However, we won't dwell on the cyclic group as it plays a minor role in the overall PoW scheme.


**Algorithm 3: Hash Function**

**Preliminaries**

Before delving into the subsequent lines of the algorithm, it's crucial to understand the hash function denoted by H() in Autolykos. This function is called Algorithm 3 and is based on the Blake2b256 hash function.

**Functionality**

The Algorithm 3 evaluates if the Blake2b256 hash of the given inputs is lower than 
. If so, it returns the hash after a modulo operation with 
, where 
 is the prime order of group 
. Should the hash exceed this value, the function iterates until a suitable hash is obtained. It should be noted that the outputs of Algorithm 3 are numeric hashes in the range Z/qZ.

**Line 2: Computation of List R**
n this line, the algorithm focuses on generating a list called 
. This list is populated with numeric hashes called 
 values. Each 
 value is produced by the function
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mtext>takeRight</mtext>
  <mo stretchy="false">(</mo>
  <mn>31</mn>
  <mo>,</mo>
  <mi>H</mi>
  <mo stretchy="false">(</mo>
  <mi>j</mi>
  <mo>&#x2225;</mo>
  <mi>h</mi>
  <mo>&#x2225;</mo>
  <mi>M</mi>
  <mo stretchy="false">)</mo>
  <mo stretchy="false">)</mo>
</math>

**Variables Explained**

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mi>j</mi>
</math>: An integer within the range 

.
h: Block height, as described earlier.

M: A constant 8kb data segment used to slow down the hash calculation.

Here, {takeRight}(31, H(...))
 essentially selects the 31 least significant bytes from the 32-byte output of the H(...) function, discarding the most significant byte.

For example, if j = 1
, then r_1 = \text{takeRight}(31, H(1 \parallel h \parallel M))
.

This operation is performed N-1
 times to populate the list R
 with N
 elements, using an incrementing j

**Lines ¾: begin while loop and guessing**

Once the list R
 is calculated, the algorithm enters a loop where it makes a nonce guess. The loop continues until a nonce is found that produces a hash less than a given target value.

`Calculate r
while true do
`

**Lines ⅚: seed for generating indexes**

Line 5, i = takeRight(8, H(m||nonce)) mod N, produces an integer in [0,N). Algorithm 3 is utilised but with m and the nonce as inputs. Once the hash H(m||nonce) is returned, the eight least significant bytes are kept and passed through mod N. As a side note, the highest possible integer value with 8 bytes is 264 – 1, and assuming N = 226_, an 8-byte hash mod N will result in the first few digits being zero. The number of zeros in i decreases as N grows.

Line 6 produces e, a seed for index generating. Algorithm 3 is called with inputs i (generated in line 5), h, and M. Then, the most significant byte of the numeric hash is dropped, and the remaining 31 bytes are kept as value e. It should also be noted that value e can be retrieved from list R instead of being computed since e is an r value.
.

**Line 7: index generator**

Element index J is created using Algorithm 6 with inputs e, m,_ and nonce. Function genIndexes is a pseudorandom one-way that returns a list of k (=32) numbers in [0,N).

**genIndexes function**

![](https://storage.googleapis.com/ergo-cms-media/unnamed_6_987fcaba80/unnamed_6_987fcaba80.png)

A couple of extra steps are not shown in the pseudocode, such as a byteswap. The creation and application of genIndexes can be explained via the following example:

GenIndexes(e||m||nonce)...

**hash** = Blake2b256(e||m||nonce) = [0xF963BAA1C0E8BF86, 0x317C0AFBA91C1F23, 0x56EC115FD3E46D89, 0x9817644ECA58EBFB]_
**hash64to32** = [0xC0E8BF86, 0xF963BAA1, 0xA91C1F23, 0x317C0AFB, 0xD3E46D89 0x56EC115F, 0xCA58EBFB, 0x9817644E]_
**extendedhash** (i.e., byteswap and concatenate 4 bytes by repeating first 4 bytes) = [0x86BFE8C0, 0xA1BA63F9, 0x231F1CA9, 0xFB0A7C31, 0x896DE4D3, 0x5F11EC56, 0xFBEB58CA, 0x4E641798, 0x86BFE8C0]_
The following python code shows slicing the extended hash, returning k indexes. In this example we are assuming h < 614,400, thus N = 226 (67,108,864).

**Slicing and mod N[1]**

`for i in range(8):
    idxs[i << 2] = r[i] % np.uint32(ItemCount)
    idxs[(i << 2) + 1] = ((r[i] << np.uint32(8)) | (r[i + 1] >> np.uint32(24))) % np.uint32(ItemCount)
    idxs[(i << 2) + 2] = ((r[i] << np.uint32(16)) | (r[i + 1] >> np.uint32(16))) % np.uint32(ItemCount)
    idxs[(i << 2) + 3] = ((r[i] << np.uint32(24)) | (r[i + 1] >> np.uint32(8))) % np.uint32(ItemCount)
`

The main takeaway is that slicing returns k indexes which are pseudorandom values derived from the seed, i.e., e, m, and nonce.

return [0x2BFE8C0, 0x3E8C0A1, 0xC0A1BA, 0xA1BA63, 0x1BA63F9, 0x263F923, 0x3F9231F, 0x1231F1C, 0x31F1CA9, 0x31CA9FB, 0xA9FB0A, 0x1FB0A7C, 0x30A7C31, 0x27C3189, 0x31896D, 0x1896DE4, 0x16DE4D3, 0x1E4D35F, 0xD35F11, 0x35F11EC, 0x311EC56, 0x1EC56FB, 0x56FBEB, 0x2FBEB58, 0x3EB58CA, 0x358CA4E, 0xCA4E64, 0x24E6417, 0x2641798, 0x179886, 0x39886BF, 0x86BFE8]

This index can be translated to values in base ten as it refers to numbers in [0, N). For instance, 0x2BFE8C0 = 46131392, 0x3E8C0A1 = 65585313, 0xC0A1BA = 12624314, and so on. The miner uses these indexes to retrieve k r values.

The genIndexes function prevents optimisations as it is extremely difficult, basically impossible, to find a seed such that genIndexes(seed) returns desired indexes.

**Line 8: sum of r elements given k**
Using the index generated in line 7, the miner retrieves the corresponding k (=32) r values from list R and sums these values. This might sound confusing but let’s break it down.

Continuing the example above, the miner stores the following indexes:

`{0 | 46,131,392},
{1 | 65,585,313},
{2 | 12,624,314},
{3 | 10,599,011},
…
{31 | 8,830,952}
`

Given the indexes above, the miner retrieves the following r values from list R stored in memory.

`{0 | 46,131,392} → _dropMsb(H(46,131,392||h||M))_
{1 | 65,585,313} → _dropMsb(H(65,585,313||h||M))_
{2 | 12,624,314} → _dropMsb(H(12,624,314||h||M))_
{3 | 10,599,011} → _dropMsb(H(10,599,011||h||M))_
…
{31 | 8,830,952} → _dropMsb(H(8,830,952||h||M))_
`

Note that Takeright(31) operated on a 32-byte hash can also be written as dropMsb (drop most significant byte).

Since the miner already stores list R in RAM, the miner does not need to compute k (= 32) Blake2b256 functions and instead looks up the values.

This is a key feature of ASIC resistance. An ASIC with limited memory needs to compute 32 Blake2b256 iterations to get the values that could have been looked up in memory, and fetching from memory takes much less time.

An ASIC with limited memory would require 32 Blake2b256 instances physically on the die to achieve one hash per cycle, which would require more area and higher costs. It's simple to prove that storing list R in memory is well worth the trade-off.

Assume the following, a GPU has a hash rate of G = 100MH/s, N = 226, k = 32, block interval t = 120 seconds, and elements are looked up every four hashes. We can assume that elements are looked up every four hashes because, for each nonce guess, multiple elements such as i, J, and H(f) require Algorithm 3, i.e. blake2b hash, instances.

We can estimate that each r value will be used, on average, (G * k * t)/(N*4) = 1430.51 times.

Once the 32 r values are looked up, they are summed.



**Line 9 - 12: check if the hash of sum is below target**

The sum of the 32 r values is hashed using Algorithm 3, and if the output is below target b, the PoW is successful, m and nonce are returned to network nodes, and the miner is rewarded in ERG. If the sum hash is above the target, Lines 4 – 11 are repeated with a new nonce.

If you have made it this far, congratulations! After reading all of this information, you should have a good understanding of Autolykos v2! If you want a visual demonstration of Autolykos, please see the graphic at the end of this document. If you would like a video explanation, you can find it [here](https://youtu.be/pPYcfLQGIHg)

.


Autolykos Line-by-line

## **Ergo's Storage Rent**

Ergo's design emphasizes long-term economic sustainability. One of the key strategies to ensure this is the implementation of storage rent or 'demurrage'. This mechanism, akin to 'on-chain garbage collection', not only mitigates the issue of blockchain bloat but also turns it into a profitable venture.

**Key Features**

Starting from block 1,051,200 (July 20th, 2023), miners can charge storage rent or fully spend the box if its value doesn't cover the rent.

Storage fees serve as an additional source of rewards for miners, supplementing block and transaction rewards.

By reducing the storage load, storage fees eliminate potential extra costs that could arise from excessive state growth.

Storage fees stimulate coin circulation and deter deflation, thereby preventing illiquidity and congestion in the currency system.

**Understanding 'Storage Rent**

Storage rent is a nominal fee levied on unspent output after four years. The fee per byte is determined by the storage rent subprotocol. For a box without tokens and complex scripts, this amounts to approximately 0.14 ERG every four years.

For a comprehensive understanding of the storage rent fees within the Ergo blockchain, including how these fees are calculated, applied, and adjusted over time, visit this page.

**What About Tokens, NFTs, etc?**

Ergo's storage rent mechanism rewards miners uniquely by allowing them to claim valuable assets within a UTXO if the ERGs available are insufficient to cover the rent. This principle applies to various assets, including NFTs and stablecoins like SigUSD, and promotes increased participation and active asset management. While it enhances network security and reduces blockchain bloat, it could lead to uninformed users inadvertently losing valuable assets if they fail to maintain enough ERGs. Users are strongly advised to thoroughly understand Ergo's storage rent mechanism and ensure they possess enough ERGs to protect their valuable assets. For more information, click here.

**How to Check the Age of Your Boxes?**
[
TokenJay](https://docs.ergoplatform.com/eco/token-jay/) offers a convenient [Box consolidation](https://tokenjay.app/app/#boxconsolidation) tool that checks the number and age of boxes in your wallet and consolidates them when necessary. [Nautilus](https://docs.ergoplatform.com/dev/wallet/nautilus/) also features a built-in box consolidation tool that alerts you if your UTxO set requires consolidation. Alternatively, you can message [@ergoportbot](https://t.me/ergoportbot) on Telegram and use the command /ep boxage ADDRESS to check.

**Additional Resources**

[How to consolidate a wallet
](https://ergonaut.space/en/Guides/how-to-consolidate-a-wallet)

[HF-4.0 Reduce storage rent period #1144 ](https://github.com/ergoplatform/ergo/issues/1144)- Rejected

[EIP-0045 Redistribution contracts for Storage Rent Fees #93
](https://github.com/ergoplatform/eips/pull/93)

[EIP-39 Monotonic box creation height rule
](https://github.com/ergoplatform/eips/blob/master/eip-0039.md)

[EIP-33: Token burning during rent collection #68
](https://github.com/ergoplatform/eips/pull/68)

[Storage rent details (ergoforum).](https://www.ergoforum.org/t/storage-rent-details/256)

Ergo's Storage Rent

## **Ergo Storage Rent Fees**

The [FeeSimulator.scala](https://github.com/ergoplatform/ergo/blob/master/src/test/scala/org/ergoplatform/tools/FeeSimulator.scala) tool offers a comprehensive means of simulating Ergo's storage rent fees. This tool aids in calculating the average byte size of a standard box based on the dimensions of two types of Pay-to-Public-Key (P2PK)-protected boxes: one containing only ergs and another containing an additional asset. Here's what the simulations reveal:

**Key Metrics**

**Average Size of a Standard Box:** 105 bytes
**Storage Rent Fee:** 0.13125 ergs for a standard box

**Projected Storage Rent:** Approximately 0.13 ergs every four years


## Connection to Transaction Fees

While Ergo doesn't mandate a minimum transaction fee on the protocol level, a crucial detail is that each box must contain a minimum value per byte, which currently stands at 360 nanoergs per byte. Miners can collectively decide to alter this number within a [0, 10,000] nanoergs per byte range. The adjustment parameters are as follows:

**Increment/Decrement Step:** 2 or -2

**Per-Epoch Adjustment Rate**: 10 nanoergs per byte

Example: Should a majority of miners opt to increase the default value during an epoch consisting of 1,024 blocks, the value for the ensuing epoch would be modified to 370 nanoergs per block.

For further details on how these fee adjustments are made, check out the [Governance section.
](https://docs.ergoplatform.com/mining/governance/)
This enables miners to consistently earn rewards from a fixed-size UTXO set over a four-year span. After that, the reward for each block becomes `perOutputFee * (numberOfBoxes / (4 * BlocksPerYear)).`

Given that Ergo's UTXO set size is in the same ballpark as Bitcoin's (~60 million), the potential block reward could look like this:

perOutputFee * (numberOfBoxes / (4 * BlocksPerYear))
0.001 * (60,000,000 / (4 * ))
Estimated Block Reward = 7.49 Ergs plus transaction fees
For an academic perspective on this topic, consult the research paper "[A Systematic Approach To Cryptocurrency Fees](https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final18.pdf)".

**Storage Rent Fee Collection**

Every four years, miners can capitalize on the opportunity to collect a storage rent fee by respending and recreating a box. In doing so, all register states remain intact, barring R0 (which holds the monetary value) and R3 (containing the creation height, transaction ID, and output index where the box originated). Network voting determines the rent fee per byte, with the default set at 1,250,000 nanoergs/byte. The adjustable range for this parameter is [0…2,500,000].

## Further Reading on Storage Rent Potential
If you're keen on diving deeper into Ergo's potential storage rent gains, here are some community-contributed resources:

[Exploring Ergo's Storage Rent Potential: Part 1
](https://www.reddit.com/r/ergonauts/comments/tyymax/tracking_storage_rent_potential/)
[Unlocking the Secrets of Ergo's Storage Rent: Part 2
](https://www.reddit.com/r/ergonauts/comments/xeke0b/discover_ergos_storage_rent_potential/)

[A Continual Look at Ergo's Storage Rent Potential: Part 3](https://www.reddit.com/r/ergonauts/comments/13e8f8g/tracking_storage_rent_potential_3rd_ed/)


Ergo Storage Rent Fees

## **What about tokens, NFTs, etc?**

Ergo's storage rent mechanism also allows miners to take over valuable assets inside a UTXO if there are insufficient ERGs to pay rent

On the positive side, this mechanism incentivizes miners by offering them additional rewards, making the Ergo blockchain more attractive and encouraging participation. This increased participation can enhance the network's security and overall health.

However, there are drawbacks to this mechanism. Users who are not aware of the storage rent system or fail to maintain enough ERG in their UTXO may lose valuable assets unintentionally.

[EIP-33: Token burning during rent collection #68](https://github.com/ergoplatform/eips/pull/68) is under discussion, which could potentially address some of these concerns in the future. However, it appears there is currently no consensus.


What about tokens, NFTs, etc?

## **How to Spend an Expired Ergo Box**

Spending an expired Ergo box involves satisfying specific conditions that differ from spending a regular box. The following criteria must be met:

## Conditions for Spending an Expired Box
**Storage Fee Duration**: The box must have been retained for at least the designated storage fee period. This is validated by calculating the difference between the height of the upcoming block, as indicated in the preheader, and the creation height of the box. This difference should be greater than or equal to the storage fee period.

**Spending Proof**: For an expired box, the spending proof must be left empty, eliminating the need for cryptographic authorization for the box's spending.

## Code Snippet for Verifying Storage Fee Duration
The following line of code checks whether the box has been stored for the required minimum duration, comparing the height of the upcoming block `(context.preHeader.height`) with the box's creation height (`context.self.creationHeight)`:

`context.preHeader.height - context.self.creationHeight >= Constants.StoragePeriod
`

**Spending Proof for Expired Boxes**

The term "spending proof" typically refers to a cryptographic authorization required for spending a box. However, in the context of an expired box, this requirement is waived. The spending proof for the expired box must be empty, meaning that no cryptographic validation is needed to authorize its spending. This allows any participant to spend the expired box without needing to prove ownership, as long as the storage fee duration condition is fulfilled.

**Additional Details for Spending an Expired Box**

If both the above conditions are met, the expired box can be spent by anyone. To do so, one needs to provide an index of a newly recreated box (or an index of any box, if the expired box lacks sufficient funds for the storage fee) in the context extension variable #127, which will be stored as part of the input.


How to Spend an Expired Ergo Box

## **Understanding Cryptocurrency Fees: A Multi-Dimensional Approach**

This article builds upon the research presented in the paper [A Systematic Approach To Cryptocurrency Fees](https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final18.pdf). Authored by Alex (Kushti) Chepurnoy, Vasily Kharin, and Dmitry Meshkov, the paper delves into the complexities surrounding blockchain storage and suggests a multi-dimensional fee structure as a solution.

## The Double-Edged Sword of Blockchain Storage

Blockchain technology is remarkable for its capabilities of ensuring security, transparency, and an immutable transaction history. However, this very feature of permanence leads to ever-expanding blockchain states, raising a series of concerns:

**Risk of Centralization:** As the state grows, fewer entities can effectively store it, escalating the centralization threat.

**Spam Attack Vulnerability:** A bloated state is an inviting target for spam and denial-of-service attacks.

**Resource Drain:** Larger states require more computational power, leading to increased operational costs.

**Deflationary Pressures:** Lost or dormant coins risk deflating the currency’s value, undermining its utility.

![](https://ergoplatform.org/img/uploads/3d.png)

The image above introduces a 3-dimensional scale to assess cryptocurrency fees based on three crucial factors: space (storage load), duration (time), and computational load. This visualization aids in understanding how a multi-faceted fee system could mitigate the inherent challenges tied to blockchain storage and resource utilization.

**Case Studies: Bitcoin and Ethereum**

To illustrate these concerns, consider the spam attack on Bitcoin in July 2015 that led to 15 million new outputs, bloating the total UTXO size significantly. Ethereum faced a similar fate with an attack that added 18 million new accounts to its state, causing resource-intensive denial-of-service attacks on nodes.

**A Multi-Faceted Solution: Storage Rent**

The paper suggests the concept of "storage rent" as a remedy. This involves a recurring fee on each Unspent Transaction Output (UTXO) aimed at deterring indefinite data storage. By implementing this mechanism, blockchain systems could become more efficient, secure, and sustainable, aligning with earlier ideas such as the 2014 Freicoin proposal for currency demurrage.

**Highlights and Contributions of the Paper**

**Dimensional Fee Complexity:** The paper breaks new ground by considering fees in three dimensions—space, time, and computation—rather than as a monolithic entity.
**Unsustainability of Unchecked Growth:** State growth, if left unchecked, risks centralization and compromised security through reliance on Simplified Payment Verification (SPV) mining.
**Innovative Fee Algorithms:** The paper introduces fresh algorithms for fee differentiation and pricing curves for storage, aiming for a more predictable and economical fee structure.

**Strategic State Management:** The paper advocates for the introduction of a fee component specifically tailored to regulate state size effectively.

**Unintended Ripple Effects:** The research also touches on the secondary impacts of storage fees, such as the reactivation of lost or dormant coins.

## Miner Costs and Ecosystem Sustainability
In a Proof-of-Work blockchain system, miners play a pivotal role, safeguarding the network's integrity at the cost of electricity and computational resources. To sustain this ecosystem, miners are compensated through block rewards and transaction fees.

In platforms like Ethereum that support smart contracts, transactions may involve substantial computational overhead, necessitating a multi-dimensional fee structure that accounts for:

**Storage Load:** Represents the costs associated with preserving historical blockchain data.
**Computational Load:** Entails the computational resources expended in executing smart contracts.

**Network Load:** Includes the bandwidth and processing capacity needed to accommodate new, yet-to-be-blocked transactions.
For instance, in the Ergo blockchain, the paper recommends introducing a "state deterioration fee." This would incentivize miners to streamline system performance by effectively managing the state size, including all UTXOs, smart contracts, and transactional data.




Understanding Cryptocurrency Fees: A Multi-Dimensional Approach

## **The Mechanics of ASIC Resistance in Autolykos v2**

Ergo's Autolykos v2 employs a dynamic strategy to resist Application-Specific Integrated Circuits (ASICs). The system achieves this through scheduled memory table adjustments, effectively increasing the minimum GPU vRAM requirements for mining over time. This ensures that any ASIC built to mine Ergo today will find itself inefficient following future updates.

**Unpacking Memory-Hardness: Lessons from Ethereum and Beyond**

Ethereum demonstrated that 'memory-hard' algorithms could still be manipulated by ASICs with on-board memory. Ergo's Autolykos v2 takes a different approach. Let's examine why ASICs with limited memory cannot compete effectively and explore the necessity of storing list R.

**Diving Deeper into Autolykos**

To fully grasp the intricacies of Autolykos v2, we recommend going through the technical breakdown line by line. Here, we provide a high-level overview:

**Line 8:** This line serves as a gatekeeper, filtering out machines that do not meet the memory requirements.

**Hash Generation:** In the absence of list R, an ASIC would require multiple cores to dynamically generate 31-byte numerical hashes.
**Single-Core Loop Limitations:** The process of generating 32 r values in a single cycle is not efficient, resulting in sparse output.

**Computational Requirements:** To compute a single nonce per hash cycle based on a given J, at least 32 instances of Blake2b256 running dropMsb(H(j||h||M)) are required.

**Cost and Efficiency:** The practice of storing list R proves to be cost-effective as fetching data from memory is quicker than performing repeated Blake2b256 hash calculations.

## Comparative Analysis: Ethash vs. Autolykos

Ethash involves N elements when hashing, while Autolykos involves N elements for fetching 32 r values based on indexes generated. Autolykos is more memory-hard due to its higher reliance on memory bandwidth

## Potential Autolykos Optimizations and Constraints

**Hashing Speed:** Speeding up the Blake2b256 function can reduce the time to fill list R, though this would entail a considerable investment in specialized hardware.

**Memory Bandwidth:** Despite minor advantages for Ethash ASIC miners in read speed, this is expected to become negligible as GPU technology advances.

**Blake2b256: Why It Matters**

Blake2b256, unlike other hashing algorithms, emphasizes addition operations over XOR, making it both secure and computationally demanding. This makes it difficult for ASICs to gain a significant advantage.

## FPGAs: A Current Assessment and Future Outlook

**Key Features and Considerations**

**Efficiency:** FPGAs can achieve up to 3Mh/W, double the efficiency of the best Nvidia cards.
**Availability:** A chip shortage and lack of public miners make FPGAs currently non-competitive.
**ROI:** If you could buy an E300 at retail prices today, the Return on Investment (ROI) would take approximately 52 years.

Community Perspective: To FPGA or Not to FPGA?#
The decision to allow or restrict FPGAs is up to the Ergo community. While FPGAs are more efficient, GPUs are more accessible, fostering greater decentralization.

**The SRAM Dilemma in FPGA Mining**

SRAM, despite its faster read/write capabilities, is not a feasible long-term option for Ergo mining due to its lower density and the algorithm's increasing memory requirements.

By understanding these components, we can appreciate how Autolykos v2 aims to create a more ASIC-resistant, secure, and ultimately, decentralized network.

The Mechanics of ASIC Resistance in Autolykos v2

## **Mining Resources**

This page provides a collection of resources related to Ergo mining. It includes academic papers, code repositories, test vectors, and discussion threads.

**Academic Papers**

[Ergo White Paper](https://www.docdroid.net/mcoitvK/ergopow-pdf): This paper provides a comprehensive overview of Ergo, including its design principles, consensus algorithm, and economic model.

[Ergo Yellow Paper:](https://www.docdroid.net/mcoitvK/ergopow-pdf) The Yellow Paper offers a more technical perspective on Ergo, detailing the platform's underlying algorithms and data structures.

["Bypassing Non-Outsourceable Proof-of-Work Schemes Using Collateralized Smart Contracts"](https://ia.cr/2020/044): This paper discusses a novel approach to bypassing non-outsourceable proof-of-work schemes using smart contracts.

Code#
The [Ergo GitHub repository](https://github.com/ergoplatform/ergo/tree/master/src/main/scala/org/ergoplatform/mining) contains the Scala files related to Ergo's mining algorithm. This is a great resource if you're interested in understanding the technical details of Ergo mining.

Test Vectors#
[Test vectors for increased N values](https://www.ergoforum.org/t/test-vectors-for-increased-n-values/2887/2): This forum post provides test vectors for Ergo's proof-of-work algorithm with increased N values.
EIPs#

[EIP27](https://docs.ergoplatform.com/mining/standards/eip27/)

[EIP37](https://docs.ergoplatform.com/mining/standards/eip37/)

Mining Resources

## **GPU vs. CPU Mining: A Comparative Analysis of Autolykos and RandomX**

The evolution of cryptocurrency mining has been marked by a constant tug-of-war between optimizing algorithms for general-purpose hardware like CPUs and GPUs, and the inevitable emergence of specialized hardware like ASICs (Application-Specific Integrated Circuits) and FPGAs (Field-Programmable Gate Arrays). As developers create new digital currencies, they must carefully consider the trade-offs between these approaches. The choice of mining algorithm can have profound impacts on key aspects of a cryptocurrency network, including decentralization, accessibility, security, and performance. In this comparative analysis, we will dive deep into the technical details and real-world implications of GPU and CPU mining, using the Autolykos and RandomX algorithms as illustrative examples.

**The Pursuit of ASIC Resistance**

One of the primary goals of many cryptocurrency projects is to achieve a high degree of decentralization by enabling mining on widely available hardware. The idea is that if specialized hardware like ASICs dominate the network, it could lead to centralization as the production and distribution of this hardware is often controlled by a small number of entities. This has led to the pursuit of ASIC-resistant algorithms that aim to level the playing field between general-purpose hardware and ASICs.

However, the concept of ASIC resistance is not without controversy. Some argue that ASICs are an inevitable consequence of a successful cryptocurrency, and that the goal should be to delay their onset rather than prevent them entirely. Others point out that the very concept of ASIC resistance is a moving target, as hardware manufacturers will always be incentivized to optimize for the most profitable algorithms.

Ergo's lead developer, kushti, has acknowledged the difficulty of achieving perfect ASIC resistance, stating "any algorithm can be optimized with specialized hardware." However, he also notes that the goal is to find a balance that maximizes decentralization while still providing sufficient network security.

**RandomX: Leveraging CPU Design**

Monero's RandomX algorithm takes a novel approach to ASIC resistance by leveraging the complexity of modern CPU design. RandomX generates PoW programs that contain a high number of random branches, which must be correctly predicted for efficient execution. This plays to the strengths of CPUs, which have highly sophisticated branch prediction units that occupy a significant portion of their circuitry.

As Wolf9466, a developer who has contributed to both Ergo and Monero codebases, explains: "The largest (in terms of physical area) and most complex circuitry in any modern high-performance CPU is the branch predictor. They do anything and everything to improve the speed and accuracy of this... RandomX contains quite a few branches in every program generated, and you must complete several for a successful PoW result. Because of this, the most efficient thing to use when mining it is a CPU - not because of some magical property of 'ASIC resistance' - but because the ASIC in question is already present in CPUs."

In essence, RandomX aims to make CPUs the most efficient "ASICs" for its algorithm by fully exploiting their microarchitectural quirks. An actual ASIC designed for RandomX would essentially need to replicate the complexity of a high-performance CPU, nullifying the efficiency gains that make ASICs attractive in the first place.

**The Decentralization Dilemma and the Botnet Threat**

Decentralization lies at the heart of what makes cryptocurrencies revolutionary. By distributing power across a vast network of participants, these systems aim to create a more equitable and resilient financial infrastructure. However, achieving true decentralization is no simple feat, and the choice of mining algorithm plays a crucial role in this endeavour.

Monero's RandomX algorithm takes a CPU-centric approach, seeking to leverage the ubiquity of general-purpose processors. In theory, this allows virtually anyone with a computer to participate in mining, promoting a more decentralized network. Yet in practice, the low barriers to entry have made RandomX a prime target for botnets. By secretly infecting countless computers with mining malware, these botnets can amass significant amounts of illicitly gained hashing power. This not only undermines the decentralization RandomX aims to achieve but also poses a security risk. The fragmentation of hashing power among botnets can make it easier for malicious actors to execute 51% attacks, depriving legitimate miners of their hard-earned rewards.

While the exact extent of botnet influence on the Monero network is unknown, some community members have speculated that botnets could account for a significant portion of the total hashrate. Core developers have estimated that botnets may contribute around 20% of the network's mining power, but the true figure remains uncertain. Regardless of the precise number, the presence of botnets poses a challenge to Monero's decentralization goals.

The largest Monero mining botnet, dubbed Smominru, is believed to have infected over 500,000 Windows computers. Another major botnet called MyKings is estimated to have minted $3 million worth of XMR. These centralized botnets pose a significant threat to the security and decentralization of the Monero network.

In stark contrast, Ergo's Autolykos algorithm embraces GPU mining. While GPUs may not be quite as ubiquitous as CPUs, they are still widely accessible thanks to the growing popularity of gaming PCs and GPU-accelerated devices. By optimizing for GPU hardware, Autolykos puts mining power in the hands of individual enthusiasts and small-scale operations. The higher cost of entry makes it far less attractive to botnets, as it's simply not economically viable for hackers to invest in racks of GPUs just to make quick mining profits. As a result, Autolykos achieves a more robust and sustainable form of decentralization compared to RandomX.

**Autolykos: Balancing GPU Accessibility and ASIC Resistance**

Ergo's Autolykos algorithm takes a different approach, seeking to strike a balance between ASIC resistance and accessibility to GPUs. While not as widely available as CPUs, GPUs are still a relatively accessible form of hardware, particularly among gaming enthusiasts and crypto miners.

In 2020, the Ergo community engaged in extensive discussions about potential improvements to the Autolykos algorithm to strengthen its ASIC resistance. These discussions culminated in a "hardening hard-fork" that implemented several key changes:

The memory-hardness of the algorithm was increased by changing the memory access patterns. This made the algorithm more resistant to optimization by specialized hardware.

The iteration count was increased, making the algorithm more computationally intensive and thus more costly to implement in ASICs.

A random program buffer was introduced to the PoW function, further increasing the complexity and irregularity of the algorithm.

These changes were designed to make Autolykos more resistant to ASIC development while still maintaining its accessibility to GPUs. By increasing the memory and computational requirements of the algorithm, the hard-fork made it more challenging to develop efficient ASICs without significantly impacting GPU mining performance.

**The Limits of Memory-Hardness**

One of the key tenets of ASIC resistance has been the concept of memory-hardness - the idea that an algorithm can be designed to be bottlenecked by memory bandwidth rather than raw computation. The theory is that this makes the algorithm more resistant to ASICs, as memory is more expensive to implement in silicon than logic gates.

However, the effectiveness of memory-hardness as an ASIC-resistance strategy has come under question in recent years. As Reuben Yap, the lead developer of Firo (formerly Zcoin), points out, "Memory hardness is probably not a valid thing anymore. Even MTP, the algo isn't really memory bound, Despite doing all their recommendations."

The availability of high-bandwidth memory solutions like HBM (High Bandwidth Memory) and the increasing use of on-chip caches in ASICs have made it more challenging to create a truly memory-bound algorithm. Moreover, the growing capacity and falling prices of memory have made it more feasible to simply brute-force the memory requirements of an algorithm.

Ergo's hardening hard-fork aimed to address these challenges by combining increased memory-hardness with other algorithmic changes designed to frustrate ASIC optimization. While it may not achieve perfect ASIC resistance, the goal was to significantly delay the development of efficient ASICs while preserving the decentralization benefits of GPU mining.

**Lithos: Advancing Decentralization in Ergo**

Ergo is actively exploring new ways to further decentralize its mining ecosystem. One promising initiative is Lithos, a project that aims to create a fully decentralized, efficient, and trustless mining pool infrastructure.

Traditionally, decentralized mining pools have faced challenges such as security concerns, lack of miner adoption, and trade-offs between efficiency and decentralization. Lithos proposes a novel solution to these issues by utilizing a new protocol that verifies miners' work, pays them accordingly, and leverages the Stratum protocol as a networking layer. This approach allows miners to directly insert necessary transactions into blocks in a decentralized and trustless manner.

By providing a low-risk opportunity for lenders to earn yield on their ERG through collateral provision to mining pools, Lithos incentivizes participation and promotes increasingly decentralized block production. The protocol is designed to be blockchain-agnostic, meaning that it could potentially support mining pools for any Proof-of-Work (PoW) blockchain.

Recent milestones, such as the completion of collateral contracts and successful demonstrations of direct transaction insertion by miners, hint at the transformative potential of Lithos. As this technology matures, it could usher in a new era of fully decentralized, efficient, and trustless mining pools, further strengthening the decentralization and security of the Ergo network.

**The Performance Paradigm**

When it comes to raw mining performance, GPUs leave CPUs in the dust. The highly parallel architecture of GPUs is tailor-made for the complex mathematical problems that form the basis of most mining algorithms. Autolykos takes full advantage of this, harnessing the immense computational throughput of GPUs to accelerate the mining process.

In comparison, RandomX's CPU-centric approach simply can't keep up in terms of hash rates. While RandomX does feature some clever optimizations to extract more performance from CPUs, they are fundamentally limited by their sequential processing model. This puts miners at a significant disadvantage, making it harder for individual participants to bring in a steady profit stream. Over time, this can lead to attrition, with disillusioned miners dropping out of the network. The end result is a more centralized, less secure network that fails to live up to the original vision of decentralized cryptocurrencies.

**Towards a Greener Future**

As cryptocurrencies continue to go mainstream, the massive energy footprint of mining is coming under increasing scrutiny. For any cryptocurrency to achieve long-term sustainability, the mining process must become more energy-efficient. Here too, GPUs have a distinct edge over CPUs.

Modern GPUs are marvels of electrical engineering, designed to deliver maximum performance per watt. When paired with an optimized algorithm like Autolykos, GPUs can crunch through mining problems while sipping power. In contrast, general-purpose CPUs are notoriously power-hungry when pushed to their limits. RandomX does little to rein in these inefficiencies, leading to significantly higher energy consumption per hash.

**Conclusion**

The pursuit of ASIC resistance remains a key consideration in the design of cryptocurrency mining algorithms. However, the landscape is constantly shifting as hardware manufacturers adapt to new algorithms and the economics of mining evolves.

RandomX and Autolykos represent two different approaches to this challenge. RandomX leverages the complexity of CPU branch prediction to make general-purpose hardware the most efficient for its algorithm. Autolykos, through its hardening hard-fork, seeks to balance ASIC resistance with GPU accessibility by increasing the algorithm's memory and computational requirements.

Yet both algorithms face ongoing challenges in staying ahead of hardware optimizations. The Ergo community's proactive approach to updating Autolykos demonstrates the need for continuous adaptation in the face of evolving hardware capabilities.

Ultimately, the goal for many projects is not an absolute preclusion of ASICs, but rather a sufficient delay in their onset to allow for a healthy period of decentralized GPU and CPU mining. By the time ASICs do inevitably arrive, the hope is that the network will be mature and stable enough to absorb their impact without compromising decentralization.

As the cat-and-mouse game between algorithm designers and hardware manufacturers continues, one thing is clear: the debate around ASIC resistance is far from settled. It is a complex and multifaceted issue that will likely continue to shape the evolution of cryptocurrency mining for years to come. Ergo's approach with Autolykos, including the hardening hard-fork, represents a thoughtful attempt to navigate this challenging landscape and preserve the benefits of decentralized GPU mining.

The choice between optimizing a mining algorithm for CPUs or GPUs is a complex one, with significant implications for the long-term health and viability of a cryptocurrency network. RandomX's CPU-centric approach offers the allure of broad accessibility but opens up risks in terms of botnet infiltration and energy inefficiency. Autolykos, with its focus on GPU mining, provides a compelling alternative. By combining wide accessibility with robust botnet resistance, ASIC resistance, and energy efficiency, Autolykos demonstrates the advantages of GPU mining in practice.

As the cryptocurrency landscape continues to evolve, developers must think holistically about the trade-offs involved in algorithm design. The success of a cryptocurrency depends not just on abstract notions of decentralization but on real-world behaviours and incentive structures. While the exact influence of botnets on Monero remains uncertain, their presence underscores the challenges of achieving true decentralization through a CPU-centric mining algorithm.

Autolykos offers a pragmatic path forward. Optimizing for GPUs aligns the interests of everyday users, professional miners, and the broader Ergo community. It provides robust resistance against botnets and ensures a more equitable hashrate distribution, all while maintaining energy efficiency and broad accessibility.

The rise of specialized hardware like ASICs and FPGAs may be inevitable, but Ergo's goal is not to completely prevent their existence. Instead, Autolykos aims to ensure that no single type of hardware gains a significant advantage over the others. This balanced approach helps to secure the network against the risks of hardware monoculture and centralization.

Moreover, initiatives like Lithos demonstrate Ergo's commitment to pushing the boundaries of decentralization. By exploring novel approaches to decentralized mining pools, Ergo is laying the groundwork for a more secure, equitable, and sustainable mining ecosystem.

GPU vs. CPU Mining: A Comparative Analysis of Autolykos and RandomX

## **EIP27: Emission Retargeting Soft-Fork**

**Ergo Tokenomics and Emission**

As a Proof of Work blockchain, Ergo has a defined emission schedule for the release of ERG tokens. When Ergo launched in 2019, there was no ICO (initial coin offering), no pre-mine and no pre-allocation of tokens to any founders or venture capitalists. Once the mainnet was activated, Ergo’s emission schedule was set to be completed within eight years with a strict supply of 97,739,925 ERG. During the first two and a half (2.5) years, the emission schedule sent a small portion of each block to the Ergo Foundation Treasury - for the purposes of funding promotion and development on Ergo. After two and a half years, the Ergo Foundation ceased to receive any rewards from the mining protocol and will have received 4.43% of the total ERG supply to fund that entity’s initiatives.

**The Original Emission Schedule**

Ergo currently mines blocks every two minutes. For the first two years, each block was set to release 75 ERG into circulation. At the end of the 2nd year, the emission rate was set to drop by 3 ERG/block with a schedule that would see block rewards further reduced by 3 ERG every three months. After eight years, the total supply of ERG would have been completely mined and the mining protocol would be reliant on transaction fees and Storage Rent to reward miners.

**EIP27 and the Adjustment of Ergo’s Emission Schedule**

Recently, the Ergo Foundation undertook the initiative to ensure the long-term sustainability of the mining protocol by proposing an amendment to the emission schedule. As the blockchain is still in the early stages of focusing on promotion and development, there was a concern that the ecosystem may need more time before the end of the eight-year emission schedule. If there are not enough dApps and users in the ecosystem at the end of the original emission schedule, there may not be enough transactions to incentivize miners to maintain the network.

Ergo’s co-founder, Alex Chepurnoy, proposed a solution to this possible scenario. The proposal, EIP27, would see Ergo emissions extended by approximately 17.38 years, thereby offering the time to develop the necessary crypto-economic security for the blockchain. The plan alters the amount of the block rewards so that a portion of the supply can be put into a remission contract that will release block rewards until approximately 2045.

On Ergo, miners enjoy the ability to suggest and vote on proposed changes to the network. With EIP27, the proposal required a 90% pass vote in order to be scheduled for implementation. The mining community voted over 90% in favor of this proposal and after successful testnet implementation, the new emission schedule is slated for deployment with block #777217.

Chepurnoy provided the following breakdown of the remission in a recent EIP27 update on an Ergo Forum post:

“If block reward is not less than 15 ERG, send 12 ERG from it to the remission contract". "Otherwise, block reward R is less than 15 ERG, send R - 3 ERG from it to the remission contract.”

These new emission rules will be integrated with the original emission schedule of the Whitepaper. Currently, block rewards are reduced every three months by 3 ERG/block - this will still be the case after EIP27 is activated. However, once implemented (approximately June 21), the block size will be 51 ERG/block. Based on the original emission schedule, the next reduction in rewards will take place around July 2, 2022. The block rewards will be reduced by 3 ERG, therefore the total reward for each block will be 48 ERG. Three months from that date, the block rewards will be 45 ERG/block, and so on. This reduction schedule will continue until block rewards are 3 ERG/block. Block rewards will remain steady at 3 ERG/block until the remission contract has been depleted.

EIP27 is a commitment to ensuring the long-term and sustained growth of Ergo. Since changes in the emission schedule can not be implemented without consensus within the mining community (90% pass is required), EIP27 represents the collaborative spirit of the Ergo community to collectively build a better blockchain for everyone. For more details on the implementation of EIP27, please see Chepurnoy's Ergo Forum post.

EIP27: Emission Retargeting Soft-Fork

## **EIP37: Tweaking Difficulty Adjustment Algorithm**

**Why Is This Important?**

The goal of a difficulty adjustment algorithm is to stabilize the time it takes to produce a new block, based on how fast blocks are being mined. In Ergo, we aim for a 120-second average block time. While Bitcoin's algorithm works well in certain conditions, it has its limitations—especially in fluctuating mining environments. Ergo's original algorithm performed well but was prone to erratic difficulty changes. This proposal aims to make the algorithm more stable and responsive.

**Background and Comparative Analysis**

Bitcoin uses a relatively simple adjustment algorithm, but it can struggle with issues like "coin hopping," where miners switch between coins to maximize profits. Ergo previously used a predictive method to anticipate such behaviors. To improve upon both, this proposal blends features from Bitcoin's "classic" algorithm and Ergo's predictive model.

**Key Proposed Changes**

Shorter Epoch Length: Reducing the epoch length to 128 blocks, making the system more responsive.
Dual Calculations: Use both a predictive method based on the last eight epochs and the classic Bitcoin-style method.
Predictive Limits: Cap the changes in predictive difficulty to a maximum of 50% per epoch.
Overall Limits: Finally, take an average of both calculated difficulties and limit changes to a maximum of 50% per epoch.
**Simulation Results**

We've simulated various scenarios including price fluctuations, consistent growth, and coin hopping. The proposed changes consistently result in lower errors and delays compared to the existing algorithms. This suggests that the proposed changes will make the algorithm more robust and efficient.

**Activation Criteria**

Activation Window: Between block #843,776 and block #851,969.
Vote Requirement: At least 232 votes for activation within the last 256 blocks.
Vote Checking: Voting status will be checked every 128 blocks.
How To Upgrade#
To adopt these changes, please update to the Ergo reference protocol client version 4.0.100 or newer.

EIP37: Tweaking Difficulty Adjustment Algorithm

## **Start Mining**

This guide will walk you through the process of starting to mine Ergo using Autolykos2.

**Prerequisites**

Before you start mining, make sure you have the following:

Familiarity with Ergo. If you're new, start with What is Ergo?
A computer with at least one GPU that has more than 6GB of memory. Check the Autolykos v2 hashrates spreadsheet for potential hashrates.
If you're considering building a dedicated rig, refer to our guide on Building a rig.
**Steps to Start Mining**

Choose your preferred mining software. If you're using a dedicated rig, select an appropriate operating system.
Set up a wallet where your mining payouts will be deposited.
Select a mining pool to join or look into solo mining
Consider overclocking your GPU to maximize your mining performance. Be aware that this can increase power consumption and potentially shorten the lifespan of your hardware.
Check out the Miner Tooling and keep an eye on ways to participate in miner governance in future.
Happy mining!

Start Mining

## **Software**

![](https://media.discordapp.net/attachments/980490396356476938/1330811283012063232/image.png?ex=678f5617&is=678e0497&hm=ce3f09af796dc118b7d812f5bc36df6e4ed12f9fd50922b6738aa104cc999ce4&=&format=webp&quality=lossless&width=532&height=393)

**Source Code Miners**

[AMD miner
](https://github.com/mhssamadani/Autolykos2_AMD_Miner)
[Nvidia miner
](https://github.com/mhssamadani/Autolykos2_NV_Miner)

**Other Miners**

[CUDA-based GPU miner for Ergo ](https://github.com/ergoplatform/Autolykos-GPU-miner)
for NVidia cards
[OpenCL miner for ERGO](https://github.com/mhssamadani/ergoAMDminer)
 for AMD cards

Software

## **Operating Systems for Mining**

Different operating systems can be used for mining Ergo. Here are some popular options along with guides on how to set up Ergo mining on them:

[Hive OS 
](https://hiveos.farm/)

[Guide: Mining Ergo on HiveOS](https://ergoplatform.org/en/blog/2022-03-22-mining-ergo-on-hiveos/)

[Guide: Mining Ergo on Windows
](https://ergoplatform.org/en/blog/2022-03-17-mining-ergo-on-windows/)

[Minerstat](https://minerstat.com/)

[Rave OS
](https://raveos.com/)

[Simple Mining OS
](https://simplemining.net/)

Each of these operating systems has its own features and benefits. Choose the one that best fits your mining setup and preferences.

Operating Systems for Mining 

## **Overclocking for Ergo Mining**

Overclocking your GPU can help maximize your mining performance. However, it's important to proceed with caution as overclocking can increase power consumption and potentially shorten the lifespan of your hardware.

Here are some resources that provide overclocking settings shared by the mining community:

[Community Overclocking Settings](https://docs.google.com/forms/d/e/1FAIpQLSfvRg_I5QumCBmMCwOHzel6bt5OOAA0uvJl_PBdKEtlpbRnVQ/viewform): This Google Form collects overclocking settings from the Ergo mining community. You can view the responses to get an idea of what settings others are using.

[Hashrate.no](https://hashrate.no/coins/ERG): This website provides information about different cryptocurrencies, including Ergo. It includes a section on overclocking settings.

[Kryptex Overclocking Database](https://www.kryptex.com/en/overclocking?device=all&algo=autolykos2&order=rating): Kryptex provides a database of overclocking settings for different GPUs and algorithms, including Autolykos2, which is used by Ergo.

Remember, every GPU is unique, and what works for others might not work for you. Always monitor your hardware's temperature and stability after applying new overclocking settings.

Overclocking for Ergo Mining

## **Mining Pools**

Mining pools are groups of miners who combine their computational resources to increase their chances of finding a block. The reward is then split among the pool members, proportional to the amount of work they contributed.

Earnings and Pool Size

While larger pools win blocks more frequently and can provide more consistent payouts, your long-term earnings should be roughly the same regardless of the pool size. In smaller pools, you might not receive a payout until the pool wins a block.

**Dual Mining**

Dual mining allows you to mine Ergo alongside other coins such as KAS and ALPH. Mining Pool Stats provides details on pools currently offering this feature natively.

**Solo Mining**

Solo mining is an option for those who wish to operate independently of mining pools. This requires setting up a node and stratum server, which can be done by following the instructions provided in our guide.

Several mining pools offer a solo port for those who prefer this method. A comprehensive list of these pools can be found on Mining Pool Stats.

**Resources**

Nice Hash is a popular platform for cryptocurrency mining and trading that supports Ergo. They hosted a live event with Ergo, which you can watch here.

**Pools**

[Kryptex](https://pool.kryptex.com/erg)

[How to start mining on Kryptex
](https://pool.kryptex.com/articles/how-to-mine-ergo-en)

[Sigmanauts Mining DAO
](https://sigmanauts.com/mining/) 

[How to start mining on Sigmanaut Pool & Earn Bonus Tokens](https://sigmanauts.com/mining/)

[How to view review current and past votes on Paideia
](https://app.paideia.im/sigmanautsminingdao)

[Sigmanauts Mining Pool DAO Discord](https://discord.gg/cZMwX347Dx)

[Sigmanauts Mining Pool DAO Telegram Chat](https://t.me/+TPc9MRparGFjZjYx)

[WoolyPooly](https://woolypooly.com/en/coin/erg)

[How to start mining Ergo (ERG) on Windows with AMD RX 4GB cards](https://www.youtube.com/watch?v=47eBVIjWYqY)

[WoolyPooly Discord
](https://woolypooly.com/discord)

[WoolyPooly Telegram Chat
](https://woolypooly.com/telegram)

[NanoPool
]([https://woolypooly.com/telegram](url)) 
[
How to start mining Ergo (ERG) on NanoPool
](https://help.nanopool.org/hc/en-us/categories/4896043358365-Ergo-ERG-pool)

[K1pool](https://k1pool.com/pool/erg)

[How to start mining on K1pool
](https://k1pool.com/pool/erg/how-to-start)

[2Miners](https://k1pool.com/pool/erg/how-to-start)

[How to start mining Ergo
]([https://erg.2miners.com/help]
[F2pool](https://www.f2pool.com/?_ga=2.253802568.1957310317.1634436769-1506845288.1634436769)

[How to mine Ergo (ERG) on f2pool
](https://f2pool.io/mining/guides/how-to-mine-ergo/)

[HeroMiners](https://ergo.herominers.com/)

[Hero Miners: How to Mine Ergo (ERG)? Complete Beginner’s Guide
](https://herominers.medium.com/how-to-mine-ergo-erg-complete-beginners-guide-608a87e89ed6)

[HeroMiners: How to mine Erg](https://ergo.herominers.com/#how-to-mine-ergo-erg)

[How to Mine Ergo? Step by Step (Youtube)](https://www.youtube.com/watch?v=4SnpCF67kyc)

SmartPools#
SmartPools are a decentralized alternative to traditional mining pools. They replace centralized mining pools with autonomous on-chain smart contracts. Keep an eye on Lithos Protocol for the next generation of mining.

Mining Pools

## **Solo Mining**

Solo mining is a method where you mine Ergo independently, without joining a mining pool. This approach can be more rewarding if you have significant mining power, but it also comes with higher variance in rewards.

Before you decide to solo mine, you might want to use this calculator to evaluate if solo mining is the right choice for you.

If you decide to proceed with solo mining, you have two options:

Use a Mining Pool's Solo Port: Some mining pools offer a solo port for miners who prefer to work independently. You can find a list of such pools on Mining Pool Stats.

Host Your Own Pool: If you prefer to have complete control over your mining process, you can set up and host your own mining pool. Our pool setup guide provides detailed instructions on how to do this.

Remember, solo mining requires a good understanding of the mining process and a significant amount of resources. Make sure to thoroughly evaluate your options before you start.

Solo Mining

## **Solo Node Configuration**

To be able to spend any ERG mined this way, you will need to include the EIP27 rules in your ergo.conf file which you run with the .jar as such

Run
`java -Xmx4g -jar ergo-5.0.4.jar --mainnet -c ergo.conf
`

ergo.conf

`    ergo {
      node {
        mining = true
      }
    chain {
      reemission {
        checkReemissionRules = true
      }
    }
    wallet {
      checkEIP27 = true
    }
    }

    scorex {
     restApi {
        ## Hex-encoded Blake2b256 hash of an API key. 
        ## Should be 64-chars long Base16 string.
        ## below is the hash of the string 'hello'
        ## replace with your actual hash generated from within swagger. 
        apiKeyHash = "324dcf027dd4a30a932c441f365a25e86b173defa4b8e58948253471b81b72cf"
      }
    }
`
You'll then either want to use the Ergo Stratum mining server or Mining Core.


Solo Node Configuration

## **Spending Mining Rewards**

This section guides miners on how to withdraw funds they have mined.

Many users have launched both a node and a miner, with the miner's pubkeyHex embedded in the node's configuration. This information explains how to identify the coins that have been mined and transfer them to another address.

**Keys Overview**

Miners may encounter various keys in different formats. Here are the key formats commonly encountered:

Base16-encoded raw public key: Mining software and mining support in the node use this format, represented as a serialized point on an elliptic curve. Miners can use this key without the need for Base58 encoding or address formation.

Pay-To-Public-Key (P2PK) addresses: These addresses are displayed in the node wallet and start with "9." In addition to the elliptic curve point, P2PK addresses also include the network prefix and a checksum, similar to Bitcoin's P2PK and P2PKH addresses.

**Mining/rewardAddress API method:**

 This method is intended for external tools that generate block candidates. It displays a special encoded script, such as 88dhgzEuTXaSfKEbxfa6vghvEGdBH39sn9h7As2Y2Z6SGd8bKXCXmRLY5JtU4g4RYBP4WcZWb3JwjXDK, used to pay a miner.

As long as you have entered the pubkeyHex from your miner into your node, you don't need to worry about the different keys you encounter.

**Viewing Your Balance and Withdrawing Funds**


After initializing your wallet, you may not see the mined coins if the initialization occurred after the corresponding blocks were mined. It's important to note that the node does not scan blocks retrospectively; it only scans new blocks after initialization. To find mined coins in this situation, you need to perform a full blockchain rescan (or launch another node on a different machine or with different ports configured in the scorex.restApi.bindAddress and scorex.network.bindAddress fields of the config). We recommend using version 3.0.1 for easier configuration.

To spend your mining rewards, follow the steps below:

**Step 1: Clear Node State (if stopping the node)**

If you intend to stop your node, you must clear its state. To do this, stop the node and remove all contents of the .ergo directory. On Mac and Linux, you may need to use the ls -a command in the directory where you ran the node to view the hidden directory.

**Step 2: Restoring a Local Wallet from the Autolykos Miner's Seed Phrase**

Retrieve the mnemonic sentence you set in the config.json when configuring your Autolykos miner. You need to restore the built-in wallet using this phrase. To restore your wallet, start the node again and send a POST request to http://[your_node_ip]:9053/wallet/restore with the following application/json content-type body:

`{
  "pass": "your_wallet_pass",
  "mnemonic": "mnemonic_sentence_from_your_miner",
  "mnemonicPass": "mnemonic_pass_if_set"
}
`

In the request, provide a new, unique pass to encrypt the wallet data on your local disk. The mnemonic field should contain the mnemonic phrase copied from your Autolykos miner's config (config.json). Pay attention to the optional mnemonicPass field, which represents the password for your mnemonic phrase. Include this field in the request only if your mnemonic phrase is protected by a password; otherwise,

remove it.

Ensure that you authorize your request by setting the correct api_key HTTP header, corresponding to the apiKeyHash you configured in the node's config file.

ATTENTION: To allow the wallet to scan all blocks from the genesis, restore the wallet before your node starts downloading full blocks. You can check the fullHeight value in the response of the /info API method. If fullHeight is null, it means your node hasn't started downloading full blocks yet.

**Step 3: Checking Your Balance**

Once your node is synchronized with the network, check the /wallet/balances API method. The response should resemble the following:

`{
  "height": 3560,
  "balance": 67500000000,
  "assets": {}
}
`

First, pay attention to the height field, which should be equal to the fullHeight displayed by the /info API route. The balance field represents the confirmed balance discovered by your wallet.

**Step 4: Making a Transaction to Spend Your Reward**

To withdraw a reward from your wallet, create a new payment transaction using the /wallet/payment/send API route. Send a POST request with the following application/json content-type body:

`{
  "address": "your_address",
  "value": 10000000
}
`

In the request, specify the address where you want to move your funds and the value representing the amount of nanoERGs you wish to transfer.

After sending the request, the node will return the transaction ID in the response. You can use the explorer to track the progress of your transaction until it gets added to a block.

Spending Mining Rewards

## **Solo Mining FAQ**

**Why Aren't My Funds Visible in My Wallet?**

When you mine, the rewards are initially linked to a time-and-pubkey lock script, not your standard P2PK address. To make these funds visible in your wallet, you need to transfer all the funds to your own address in the node wallet. Once the transfer is confirmed on the chain, the Explorer will display them.

**Why Do My Rewards Go to a Different Address?**

Mining rewards are initially directed to UTXOs (Unspent Transaction Outputs) associated with specific scripts. These scripts lock the rewards to the miner's public keys for 720 blocks. You can see an example of such a script here.

These UTXOs are not part of the node wallet before the locking height, so they are not included in your balance. However, they are stored in a special node application with id = 9 (wallet application id = 10). You can locate them via the /scan/unspentBoxes/9 API endpoint.

After 720 confirmations, the wallet will display the mined rewards, even if they are still associated with long scripts instead of short P2PK addresses.

**How Do I Verify If a Block Is Mined by Me?**

You can obtain your mining rewards address with the /mining/rewardAddress API call. The response should look something like this:

`{
“rewardAddress”: “mPdcmQkPPvyMGoCDNg9oiasLyPpKJhHjgjpt89uJZE1oN9PJ9fKbdKDcfomtWoy3d1E7RFLTUbXbt1AS”
}
`

You can then verify your rewards on the Ergo Explorer.
You can also obtain your "raw" public key via the /mining/rewardPublicKey endpoint:

`{
“rewardPubkey”: “03aa53abda9e6c958ed6046e6092b901662a26a01a2029c417b1c3f29b4b1c2799”
}
`

Then, you can check block headers (pk field) for this public key.

​/mining​/solution API Endpoint

`{
  "pk": "0350e25cee8562697d55275c96bb01b34228f9bd68fd9933f2a25ff195526864f5",
  "w": "0366ea253123dfdb8d6d9ca2cb9ea98629e8f34015b1e4ba942b1d88badfcc6a12",
  "n": "0000000000000000",
  "d": 987654321
}
`

pk is the public key in binary format

n is the nonce

w and d are no longer used in Autolykos2 and are constant.

Solo Mining FAQ

## **Hosting a Pool on Ergo**

Hosting a pool on Ergo involves setting up a local instance of the Ergo node and configuring it to point to your pool software. This guide will walk you through the process step by step.

Step 1: Set Up the Ergo Node#
First, you need to set up a local instance of the Ergo node. You can find detailed instructions on how to do this here.

Step 2: Choose Your Pool Software#
Next, you need to choose your pool software. Ergo supports two options: Miningcore and Ergo Stratum Server. Choose the one that best suits your needs.

Step 3: Configure Your Miner#
Finally, you need to configure your miner to point to your pool software. Depending on your hardware, you can use either the NV or AMD miner.

Community support available on Discord.

Congratulations! You have now set up your own Ergo mining pool. Happy mining!



Hosting a Pool on Ergo

## **Stratum**

**ErgoStratum**

Stratum mining server for Ergo.

Setup a [Ergo Node for solo mining](https://docs.ergoplatform.com/mining/setup/solo-node/), making sure to include the EIP27 rules.
Setup [ErgoStratumServer](https://github.com/mhssamadani/ErgoStratumServer)

 (the pool server)
(Optional) Point [ergo-nomp](https://github.com/btclinux/ergo-nomp),
 a node open mining portal configured for ergo to both.
For the Miner Connection and Work Management, ErgoStratumProxy is also available and is used when you want to mine with open source miner (client side app).

**start.js**

`"daemons": [
        {   //Main daemon instance
            "host": "NODE IP ADDRESS",
            "port": 9053,
            "user": "",
            "password": ""
        }
    ],
`

Make sure to update varDiff depending on your hardware.

`/* Each pool can have as many ports for your miners to connect to as you wish. Each port can
       be configured to use its own pool difficulty and variable difficulty settings. varDiff is
       optional and will only be used for the ports you configure it for. /
"ports": {
        "3032": { //A port for your miners to connect to
            "diff": 240000,//the pool difficulty for this port
            /*
            * use this parameter to multiply difficulty to b for each request.
            * some miner like NBMiner does not support difficulty method of stratum.
            * if you want your pool work with these miners set this parameters.
            *
            * /
            "multiplyDifficulty": true,
            / Variable difficulty is a feature that will automatically adjust difficulty for
               individual miners based on their hashrate in order to lower networking overhead */
            "varDiff": {
                "minDiff": 240000,//Minimum difficulty
                "maxDiff":  16431986528747520,//Network difficulty will be used if it is lower than this
                "targetTime": 15, //Try to get 1 share per this many seconds
                "retargetTime": 10, //Check to see if we should retarget every this many seconds
                "variancePercent": 30, //Allow time to very this % from target without retargeting
            }
        },
        "3256": { //Another port for your miners to connect to, this port does not use varDiff
            "diff":  240000,//The pool difficulty
`

**Troubleshooting**

Have you tried turning it off and on again?
Is your ergo.conf configured correctly?
You can rescan from swagger
Join the 🃏│solo-mining channel on our Discord for community support.
The Node needs to be fully syncronised. Make sure your wallet is also unlocked.
Try adjusting difficulty in start.js if you're getting No new blocks debug errors.
If you get fatal:unable to connect to github.com, you need to run git config --global url.https://github.com/.insteadOf git://github.com/

**Resources**

**Youtube**

[Ergo Node + Stratum Server mining tutorial
](https://www.youtube.com/watch?v=_1M8dGpfKjU)

[Youtube: Mine Ergo from your own Node](https://www.youtube.com/watch?v=ubov4oweA20)



Stratum

## **Miningcore**

The following tutorial is written for Linux; see [this page if you're using Windows 10](https://docs.ergoplatform.com/mining/setup/pool_win/)


**Download [miningcore](https://github.com/oliverw/miningcore)**

You must deploy a working [PostgreSQL database](https://www.postgresql.org/download/)
Install and configure PostgreSQL#
If you are deploying in production, you need to be careful on I/O and disk/CPU/memory as a public Miningcore API will pound on your database. Keep all things default for now; [here's a good simple](https://www.postgresqltutorial.com/install-postgresql/) article

Installing Miningcore will depend if you are on Windows or Linux. Pay close attention to the dependencies needed as depicted in the README. Stay away from docker unless you're sure.

**Load the schema**

Miningcore operates under the schema miningcore by default.

**Login to Postgres**

`sudo -u postgres psql
`

**Create schema**


`CREATE ROLE miningcore WITH LOGIN ENCRYPTED PASSWORD 'your-secure-password';
CREATE DATABASE miningcore OWNER miningcore;
`

**Load the schema.**

You MUST be able to connect to your database with the psql command before trying this.

As the Postgres operating system user, run:

`psql -d miningcore -f miningcore/src/Miningcore/Persistence/Postgres/Scripts/createdb.sql
`

**Apply partitions for the shares table**

Do this upfront even if you don't think you will need it:

`psql -d miningcore -f miningcore/src/Miningcore/Persistence/Postgres/Scripts/createdb_postgresql_11_appendix.sql
`

**Create your new pool.**

You do this ONCE for each new pool you create.

`CREATE TABLE shares_mypool1 PARTITION OF shares FOR VALUES IN ('mypool1');
`

mypool1 becomes the unique identifier for your pool. Name it wisely

Configure a pool config named .json, and place it in the build directory of miningcore.

Miningcore config.json example: https://github.com/oliverw/miningcore/wiki/Configuration

Example Ergo config.json:

(NOTE: You MUST update the YOURPOSTGRESQL_PASSWORD_GOES_HERE and YOUR_REWARD_ADDR_GOES_HERE variables if copy and pasting this config as well modify the rewardRecipients percentage to fit your pool's scheme and enable the paymentProcessing section if you plan to utilize share payouts for your pool)

`{
    "logging": {
        "level": "info",
        "enableConsoleLog": true,
        "enableConsoleColors": true,
        // Log file name (full log) - can be null in which case log events are written to console (stdout)
        "logFile": "core.log",
        // Log file name for API-requests - can be null in which case log events are written to either main logFile or console (stdout)
        "apiLogFile": "api.log",
        // Folder to store log file(s)
        "logBaseDirectory": "/path/to/logs", // or c:\path\to\logs on Windows
        // If enabled, separate log file will be stored for each pool as <pool id>.log
        // in the above specific folder.
        "perPoolLogFile": false
    },
    "banning": {
        // "integrated" or "iptables" (linux only - not yet implemented)
        "manager": "Integrated",
        "banOnJunkReceive": true,
        "banOnInvalidShares": false
    },
    "notifications": {
        "enabled": true,
        "email": {
            "host": "smtp.example.com",
            "port": 587,
            "user": "user",
            "password": "password",
            "fromAddress": "info@yourpool.org",
            "fromName": "pool support"
        },
        "admin": {
            "enabled": false,
            "emailAddress": "user@example.com",
            "notifyBlockFound": true
        }
    },
    // Where to persist shares and blocks to
    "persistence": {
        // Persist to postgresql database
        "postgres": {
            "host": "127.0.0.1",
            "port": 5432,
            "user": "miningcore",
            "password": "YOURPOSTGRESQL_PASSWORD_GOES_HERE",
            "database": "miningcore"
        }
    },
    // Generate payouts for recorded shares and blocks
    "paymentProcessing": {
        "enabled": true,
        // How often to process payouts, in milliseconds
        "interval": 600,
        // Path to a file used to backup shares under emergency conditions, such as
        // database outage
        "shareRecoveryFile": "recovered-shares.txt"
    },
    // API Settings
    "api": {
        "enabled": true,
        // Binding address (Default: 127.0.0.1)
        "listenAddress": "127.0.0.1",
        // Binding port (Default: 4000)
        "port": 4000,
        // IP address whitelist for requests to Prometheus Metrics (default 127.0.0.1)
        "metricsIpWhitelist": [],
        // Limit rate of requests to API on a per-IP basis
        "rateLimiting": {
            "disabled": false, // disable rate-limiting all-together, be careful
            // override default rate-limit rules, refer to https://github.com/stefanprodan/AspNetCoreRateLimit/wiki/IpRateLimitMiddleware#defining-rate-limit-rules
            "rules": [
                {
                    "Endpoint": "*",
                    "Period": "1s",
                    "Limit": 5
                }
            ],
            // List of IP addresses excempt from rate-limiting (default: none)
            "ipWhitelist": []
        }
    },
    "pools": [
        // Repeat the following section for multiple coins
        {
            // DON'T change the id after a production pool has begun collecting shares!
            "id": "ergo1",
            "enabled": true,
            "coin": "ergo",
            // Address to where block rewards are given (pool wallet)
            "address": "YOUR_REWARD_ADDR_GOES_HERE",
            // Block rewards go to the configured pool wallet address to later be paid out
            // to miners, except for a percentage that can go to, for examples,
            // pool operator(s) as pool fees or or to donations address. Addresses or hashed
            // public keys can be used. Here is an example of rewards going to the main pool
            // "op"
            "rewardRecipients": [
                {
                    // Pool wallet
                    "address": "YOUR_REWARD_ADDR_GOES_HERE",
                    "percentage": 100
                }
            ],
            // How often to poll RPC daemons for new blocks, in milliseconds
            "blockRefreshInterval": 400,
            // Some miner apps will consider the pool dead/offline if it doesn't receive
            // anything new jobs for around a minute, so every time we broadcast jobs,
            // set a timeout to rebroadcast in this many seconds unless we find a new job.
            // Set to zero to disable. (Default: 0)
            "jobRebroadcastTimeout": 10,
            // Remove workers that haven't been in contact for this many seconds.
            // Some attackers will create thousands of workers that use up all available
            // socket connections, usually the workers are zombies and don't submit shares
            // after connecting. This features detects those and disconnects them.
            "clientConnectionTimeout": 600,
            // If a worker is submitting a high threshold of invalid shares, we can
            // temporarily ban their IP to reduce system/network load.
            "banning": {
                "enabled": true,
                // How many seconds to ban worker for
                "time": 600,
                // What percent of invalid shares triggers ban
                "invalidPercent": 50,
                // Check invalid percent when this many shares have been submitted
                "checkThreshold": 50
            },
            // Each pool can have as many ports for your miners to connect to as you wish.
            // Each port can be configured to use its own pool difficulty and variable
            // difficulty settings. 'varDiff' is optional and will only be used for the ports
            // you configure it for.
            "ports": {
                // Binding port for your miners to connect to
                "3052": {
                    // Binding address (Default: 127.0.0.1)
                    "listenAddress": "0.0.0.0",
                    // Pool difficulty
                    "difficulty": 0.02,
                    // TLS/SSL configuration
                    "tls": false,
                    "tlsPfxFile": "/var/lib/certs/mycert.pfx",
                    // Variable difficulty is a feature that will automatically adjust difficulty
                    // for individual miners based on their hash rate in order to lower
                    // networking overhead
                    "varDiff": {
                        // Minimum difficulty
                        "minDiff": 0.01,
                        // Maximum difficulty. Network difficulty will be used if it is lower than
                        // this. Set to null to disable.
                        "maxDiff": null,
                        // Try to get 1 share per this many seconds
                        "targetTime": 15,
                        // Check to see if we should retarget every this many seconds
                        "retargetTime": 90,
                        // Allow time to very this % from target without retargeting
                        "variancePercent": 30,
                        // Do not alter difficulty by more than this during a single retarget in
                        // either direction
                        "maxDelta": 500
                    }
                }
            },
            // Recommended to have at least two daemon instances running in case one drops
            // out-of-sync or offline. For redundancy, all instances will be polled for
            // block/transaction updates and be used for submitting blocks. Creating a backup
            // daemon involves spawning a daemon using the "-datadir=/backup" argument which
            // creates a new daemon instance with it's own RPC config. For more info on this,
            // visit: https:// en.bitcoin.it/wiki/Data_directory and
            // https:// en.bitcoin.it/wiki/Running_bitcoind
            "daemons": [
                {
                    "host": "127.0.0.1",
                    "port": 9052, //ERGO TESTNET DAEMON DEFAULT PORT // MAINNET IS 9053
                    "user": "",
                    "password": "",
                    // Enable streaming Block Notifications via ZeroMQ messaging from Bitcoin
                    // Family daemons. Using this is highly recommended. The value of this option
                    // is a string that should match the value of the -zmqpubhashblock parameter
                    // passed to the coin daemon. If you enable this, you should lower
                    // 'blockRefreshInterval' to 1000 or 0 to disable polling entirely.
                    "zmqBlockNotifySocket": "tcp://127.0.0.1:15101",
                    // Enable streaming Block Notifications via WebSocket messaging from Ethereum
                    // family Parity daemons. Using this is highly recommended. The value of this
                    // option is a string that should  match the value of the --ws-port parameter
                    // passed to the parity coin daemon. When using --ws-port, you should also
                    // specify --ws-interface all and
                    // --jsonrpc-apis "eth,net,web3,personal,parity,parity_pubsub,rpc"
                    // If you enable this, you should lower 'blockRefreshInterval' to 1000 or 0
                    // to disable polling entirely.
                    "portWs": 18545,
                }
            ],
            // Generate payouts for recorded shares
            "paymentProcessing": {
                "enabled": false, //ENABLE FOR SHARE PAYOUT FEATURE
                // Minimum payment in pool-base-currency (ie. Bitcoin, NOT Satoshis)
                "minimumPayment": 0.01,
                "payoutScheme": "PPLNS",
                "payoutSchemeConfig": {
                    "factor": 2.0
                }
            }
        }
        // This section ends here. Add `,` after `}` if this is not the last coin section
    ]
}
`


**Start the pool**

You should configure it to auto-start via a startup script.

`cd build
Miningcore -c <your config>.json
`

We use a different pool-specific startup configuration, so you may have to play around with it. The JSON config specifies the log files you should look at for startup errors/issues/etc. If you got this far, below is the startup log message you should get indicating you are running a healthy miningcore ergo pool:

**Indicates your Node is online and synced**

`[2022-03-16 14:26:12.9080] [I] [ergo1] All daemons online
[2022-03-16 14:26:12.9345] [I] [ergo1] Daemon is synced with blockchain
`
**Indicates Pool is online**

`[2022-03-16 14:26:14.4346] [I] [ergo1] Pool Online
`

**Indicates the diff setting, your fee, and that its a go:**

`Mining Pool:            <YOUR POOL NAME>
Coin Type:              ERG [ERG]
Network Connected:      <testnet|mainnet>
Detected Reward Type:   POW
Current Block Height:   <BLOCKHEIGHT>
Current Connect Peers:  5
Network Difficulty:     <NETWORK DIFF>
Network Hash Rate:      <NETWORK HASHRATE>
Stratum Port(s):        3056, 4056, 3156, 4156  <THIS SHOULD BE THE PORTS YOU HAVE CONFIGURED>
Pool Fee:               <YOUR FEE>
`

Pay close attention to the stats above in regards to the network. If your diff setting is wrong, the network difficulty won't be right.

If you host your miner, pool, or node on separate machines, you'll need to open ports to allow that traffic.

Illustration of initial mining traffic:

Miner ->
(connects on your defined Stratum port i.e. 3746) ->
pool server ->
connects to node RPC (9053, mainnet or 9052, testnet) ->
node
Once connections are established, traffic becomes bi-directional.

You will not need to open ports if any of the above layers are on the same machine. Internal traffic runs via the internal loop (localhost).

Typically, machines block incoming traffic (but allow outgoing) by default. If you're testing on LAN, you'll need to open these ports on your OS's firewall. But when you get to WAN, you'll additionally need to set up port forwarding on your network router.





Miningcore

## **Governance**


Ergo's governance model is designed to facilitate network upgrades and parameter adjustments through a decentralized voting mechanism among miners. This approach ensures the long-term economic stability and adaptability of the Ergo network.

Ergo implements various measures to prevent disruptive hard forks, such as pushing complexity to the application layer and enabling many features to be implemented via soft-forks. For more information on Ergo's forking mechanism, see the Forking page.

Miners can vote to change specific protocol parameters, as outlined in the table on the Forking page. Soft-forking changes that require 90% miner support can alter many aspects of Ergo, excluding critical elements like the maximum supply.

For detailed information on the voting process, including voting mechanics, system constants, and how to propose and vote for changes, refer to the dedicated Voting page.

Governance

## **Voting Cycles and Types of Changes**

Votes on foundational changes, such as block version, span 32 epochs and demand a 90% miner consensus. Everyday changes, like block size adjustments, require only a simple majority. Each block allows miners to cast votes for up to two everyday changes and one foundational change. These votes are included in the block's header.

Voting Mechanics#
Affirmative Votes#
To vote "Yes" for a change at the beginning of an epoch, a miner places the change's identifier directly into the block header.

Negative or Neutral Votes#
To vote "No" or abstain, a miner enters a zero value in place of the identifier byte in the block header.

System Constants#
Epoch length for voting: 1024 blocks
Epochs needed for foundational change: 32
Epochs before activating approved foundational change: 128
Current Network Settings#
Maximum block size: 1271009 bytes
Maximum box size: 4096 bytes
Maximum transaction size: 96kb
Parameters Table#
The following table describes vote identifiers, default values (during launch), possible steps, and minimum and maximum values.

If the step is not defined in the table, its value is defined as 
.
If the minimum value for a parameter is not defined, it equals zero.
If the maximum value is not defined, it equals 1,073,741,823.
A miner includes a parameter identifier (
) into the block header to propose or vote for increasing a parameter.

If the miner supports decreasing the parameter, they would include (
) into the block header.

![](https://media.discordapp.net/attachments/980490396356476938/1331576695987114087/image.png?ex=67921eef&is=6790cd6f&hm=af7fc1cb958ebf0d22f4bbbd19eaedc62b6ddcc43775be0f27229ebceb0d3da0&=&format=webp&quality=lossless&width=984&height=846)

Parameter values are to be written into the extension section on the first block of a voting epoch, that is, in the extension of a block when its  height\,mod\,1024 = 0
.

Parameters for the initial moment of time~ (height = 1)
 are hardcoded.

How to Propose and Vote for Changes#
To propose a change, a miner includes the vote identifier in the first block's header of a voting epoch. The header has three slots: two for everyday changes and one for soft forks. A zero should be set in any unoccupied slot. Votes can be arranged in any sequence.

For example, if a miner proposes to increase the storage fee factor and also initiate a soft-fork, they would input (0, 1, 120) in the header slots.

Voting Cycles and Types of Changes

## **Forking**

**Overview**

Ergo's view is that disruptive hard forks should be avoided unless absolutely critical. Ergo implements various measures to prevent hard forks, such as pushing complexity to the application layer and enabling many things to be implemented via soft-forks.

If a supermajority (90%+) of the network accepts a new feature, it is activated; however, old nodes that do not upgrade continue to operate normally and skip over this feature validation.

**Fork Types**

[**Velvet-Fork**](https://docs.ergoplatform.com/mining/gov/velvet-fork/): Only requires a minority of nodes to upgrade. Introduced by the NiPoPoW paper, the key idea is that you can use the scheme even if only some blocks in the chain include the interlink structure and allows for "gradual deployment" without harming the miners that haven't upgraded to the new rules. In this way, it acts similar to a soft fork in that clients that upgrade to new rules are still compatible with those that don't.

[**Soft-fork**](https://docs.ergoplatform.com/mining/gov/soft-fork/): Requires some nodes to upgrade. The recent re-emission Soft-Fork EIP37 was possible as it's enforced on miner nodes only via protocol rules. These can be approved with 90% support from miners.

[**Hard-Fork**](https://docs.ergoplatform.com/mining/gov/hard-fork/): Requires all nodes to upgrade.

**Additional Information**

For more information, refer to the Ergo Improvement Proposals (EIPs).

**Fork Prevention Measures**

Ergo employs various measures to prevent disruptive hard forks:

Pushing complexity to the application layer: By keeping the core protocol simple and pushing complexity to the application layer, Ergo reduces the need for frequent protocol-level changes that could lead to hard forks.
Enabling soft-forks: Many features and improvements can be implemented through soft-forks, which allow for backward compatibility and gradual adoption without disrupting the network.

**Fork Activation Process**

When a new feature or change is proposed, it goes through the following process:

**Proposal and Discussion**: The proposed change is discussed and evaluated by the Ergo community and developers.

**Consensus and Approval**: If the proposal gains consensus and is approved, it is scheduled for implementation.

**Fork Type Determination**: Based on the nature of the change, it is determined whether a velvet-fork, soft-fork, or hard-fork is required.

**Activation**: If a supermajority (90%+) of the network accepts the new feature, it is activated. Old nodes that do not upgrade continue to operate normally and skip over the new feature validation.
By following this process and leveraging the various fork types, Ergo aims to maintain a stable and secure network while enabling continuous improvement and innovation.

Forking

## **Soft Forks**

A soft fork is a backward-compatible protocol update that introduces new rules or deactivates existing ones without requiring a hard fork. Soft forks allow the Ergo network to evolve and incorporate improvements while maintaining compatibility with non-upgraded nodes. This approach ensures a smooth transition and minimizes disruption to the network.

## Overview
Ergo's soft-fork mechanism is governed by a strict voting process that involves miners and unfolds over a series of epochs. The process is designed to ensure that protocol changes are introduced in a transparent and decentralized manner, with the support of a significant majority of the network.

**The soft-fork process consists of the following key stages:**

**Proposal**: A soft-fork proposal is initiated by a miner, signaling the start of the voting process.
**Voting**: The voting process spans multiple epochs, during which miners cast their votes for or against the proposed change.

**Activation**: If the proposal secures the required support, an activation period begins, preparing the network for the implementation of the new protocol rules.

**Implementation**: At the end of the activation period, the new protocol rules come into effect, and the network operates under the updated rules.

## Soft-Fork Mechanism in Ergo
Soft forks in the Ergo blockchain allow for backward-compatible protocol updates, enabling the network to introduce new rules or deactivate existing ones without requiring a hard fork. The soft-fork process is governed by a strict voting mechanism that involves miners and unfolds over a series of epochs. This article outlines the key steps, rules, and technical details involved in implementing a soft fork in the Ergo blockchain.

**Preconditions for a Soft Fork**

**Software Update**: A protocol developer releases an updated version of the Ergo software that includes changes to existing rules or introduces new ones. This updated software version is made available to miners and nodes on the network.

**Proposal**: A soft-fork proposal is initiated when a miner includes a specific identifier (e.g., 120) in the first block of a new epoch, signaling the start of the voting process.

**Voting Process**

**Duration**: The voting process spans 32 epochs, each consisting of 1,024 blocks. The total voting period thus covers 32,768 blocks.

**Threshold**: For a soft fork to be approved, it must receive at least 90% of the total votes, which equates to a minimum of 29,491 votes out of a possible 32,768.

**Negative Outcome**: If the proposal fails to meet the 90% threshold, the voting process concludes, and new proposals can be initiated in the subsequent epoch.

**Positive Outcome**: If the proposal secures the required votes, an activation period of 32 epochs begins immediately.

**Activation and Implementation**

**Activation Period**: Following a successful vote, the network enters an activation phase that lasts for 32 epochs. During this period, the network prepares for the implementation of the new protocol rules.

**Activation Height**: The first block following the activation period is referred to as the 'activation height.' It is at this point that the new protocol rules come into effect.

**Block Versioning**: The block version is updated in the extension sections starting from the first block of the activation period. However, the protocol version in the block headers is only updated at the activation height.

**Technical Details**

Validation Rules and Soft-Fork Process: Specific validation rules in Ergo, as outlined in the ValidationRules.scala file, can be toggled or introduced during a soft-fork. These rules are flagged as mayBeDisabled, allowing the protocol to adapt to new requirements without breaking backward compatibility. For instance, the exCheckForkVote rule ensures that voting for a new fork is only permissible after the activation period of a previous soft-fork.

**Block Generation and Soft-Fork Voting**: The process of block generation in Ergo is tightly integrated with the soft-fork voting mechanism. As seen in the CandidateGenerator.scala file, blocks are generated with considerations for whether they should include votes for a soft-fork based on the current height and state context. This logic ensures that votes are accurately recorded and the network remains synchronized during the voting period.

**Fork-Ordering Logic**: The forkOrdered method plays a crucial role in determining whether the conditions for a soft-fork are met. This method checks the current block height, protocol version, and voting results to decide whether a soft-fork should proceed. This ensures that the network only moves forward with a soft-fork when all predefined conditions are satisfied.

**Examples**

**Starting a Vote**: Assume a vote is proposed in block #1024 by including the identifier "120" in the extension section. If 500 votes are collected in that epoch, the next epoch's block (#2048) should include the pairs 122: 1024 (indicating the start height of the vote) and 121: 500 (indicating the votes collected).

**Counting Votes**: If the next epoch (starting at block #2048) gathers an additional 600 votes, the block at height #3072 should include the updated pairs 121: 1100 and 122: 1024.

**Vote Outcome**: If the total votes collected between blocks #1024 and #33791 do not exceed 29,491, the vote fails, and new voting parameters can be initiated in the following epoch (starting at block #34816).

**Vote Success and Activation**: If the vote is successful, with more than 29,491 votes collected, the activation period begins immediately after block #33792. During the 32-epoch activation period, no new soft-fork proposals can be introduced. At the end of this period, the protocol version is updated in the block headers at the activation height, and the new rules take effect.

For more practical examples and a detailed discussion on soft-fork voting, refer to this Ergo Forum post.

Soft Forks

## **Velvet Forks**

Velvet forking is a novel approach introduced in the paper "[A Wild Velvet Fork Appears! Inclusive Blockchain Protocol Changes in Practice](http://diyhpl.us/~bryan/papers2/bitcoin/A%20wild%20velvet%20fork%20appears:%20Inclusive%20blockchain%20protocol%20changes%20in%20practice%20-%202018.pdf)" by Zamyatin et al. It allows for introducing protocol changes in a backward-compatible and inclusive manner. The key idea is to render modifications to the protocol backward-compatible, enabling a gradual deployment without harming miners who have not upgraded to the new rules.

Velvet forks are a special form of protocol update where the new set of reducing protocol rules P' is conditionally applied only when the considered elements, such as blocks or transactions, are valid under the new rules. If not, the new rules are ignored, and the previous protocol rules P are relied upon to determine validity. Since the new rules in P' are reducing, velvet protocol changes never incur a permanent protocol fork, as any element considered valid under P' is also considered valid under P.

**The key advantages of velvet forks are:**

**Inclusive Deployment**: They do not require support from a majority of participants and can potentially avoid rule disagreement forks altogether. Legacy nodes remain unaware of the changes introduced by the velvet fork.

**Backward Compatibility**: Valid blocks adhering to the new rules are also valid blocks under the old rules, ensuring compatibility with non-upgraded nodes.

**Gradual Adoption**: Velvet forks leverage the consensus mechanism of the existing protocol P to bootstrap their own consensus rules P', allowing for a gradual adoption of the new rules.

While velvet forks present a promising approach for introducing protocol changes, they may also introduce new potential attacks and threats, as well as impact the game-theoretic incentives of the underlying blockchain. Further research is needed to understand the security implications of velvet forks and their potential applications in various blockchain protocols.

Ergo's design allows for the implementation of velvet forks, enabling the introduction of new features and protocol changes in a backward-compatible and inclusive manner. This capability is particularly useful for incorporating auxiliary protocols and data from miners, as well as enabling the gradual deployment of scaling solutions and other improvements without disrupting the network or requiring a hard fork.

Velvet Forks

## **Hard Forks in Ergo**

**Overview**

In the context of the Ergo blockchain, a hard fork typically involves significant changes to the underlying consensus mechanism or core protocol rules, which require all nodes or participants in the network to upgrade to the new version of the software. If a portion of the network's participants do not upgrade, the blockchain splits into two separate chains, with the new chain following the updated protocol and the old chain following the previous one.

**Why Hard Forks Are Necessary**

**Hard forks are necessary for several reasons:**

Major Upgrades: Introducing new features or changing core mechanics of the blockchain, such as changes in the consensus algorithm, transaction validation rules, or other fundamental properties that require all nodes to operate under the new rules.

**Bug Fixes**: Addressing critical vulnerabilities that cannot be patched via soft forks or minor updates. These bugs could potentially threaten the security of the entire network.

**Governance Decisions**: Implementing decisions made by the community or core developers that require a clean break from previous rules, such as changes in monetary policy or governance structures.

**How Hard Forks Are Implemented in Ergo**

The implementation of a hard fork in Ergo follows these general steps:

**Development and Testing**:

New protocol rules are developed and rigorously tested in a controlled environment, typically a testnet or developer network. This is crucial to ensure that all changes work as intended and do not introduce new issues.

The ForkResolutionSpec file, found in the Ergo GitHub repository, is an example of how forks are tested. This file contains integration tests designed to validate the behavior of the network during and after the fork, ensuring that the nodes correctly resolve different chain forks and eventually converge on a single valid chain.

`it should "Fork resolution after isolated mining" in {
    // Test scenario ensuring that nodes resolve forks correctly after isolated mining periods
}
`

**Coordination with the Network**:

Developers coordinate with miners, node operators, and the broader community to schedule the fork. Communication is crucial, as all participants need to update their software to the new version by a certain block height or date.

The node configuration files, such as nodes.conf, play a significant role in setting up the environment for the fork. This file specifies the settings for different nodes in the network and ensures that they are all synchronized and ready for the protocol change.

`nodes = [
    { scorex { network.nodeName = node01 } },
    { scorex { network.nodeName = node02 } },
    ...
]
`

**Activation and Monitoring**:

At the predetermined block height or time, the new protocol rules are activated. The network continues to operate, but now all participants are following the new set of rules.

Post-fork, developers and node operators monitor the network for any anomalies or issues that may arise as a result of the fork.

**Handling Divergence**:

In the event that some nodes do not upgrade, the blockchain may split into two, creating a new chain (following the new rules) and a legacy chain (following the old rules). The ErgoValidationSettings class in the Ergo core provides mechanisms to enforce these new rules, ensuring that nodes adhering to the new rules can correctly validate blocks and transactions.

`case class ErgoValidationSettings(
    rules: Map[Short, RuleStatus],
    sigmaSettings: SigmaValidationSettings,
    updateFromInitial: ErgoValidationSettingsUpdate
) extends ValidationSettings with BytesSerializable {
    // Validation logic for new rules
}
`
**When to Use Hard Forks**

**Protocol Upgrades**: When a major new feature or change needs to be implemented that is not backward-compatible.

**Security Fixes**: When critical vulnerabilities are discovered that cannot be addressed through a soft fork.

**Consensus Changes**: When the community decides to make fundamental changes to the consensus algorithm or governance model.

**Conclusion**

Hard forks are a powerful tool in the evolution of the Ergo blockchain, allowing for significant changes and improvements. However, they require careful planning, coordination, and communication to ensure the network remains secure and functional during and after the transition. As with any major change, thorough testing and validation are essential to avoid disruptions.

For further details on how these processes are implemented and tested within the Ergo blockchain, you can explore the relevant code and configuration files available in the Ergo GitHub repository.

Hard Forks in Ergo

## **Sustaining Ergo Mining: Revenue Streams Beyond Emissions**

As Ergo's emission schedule is set to conclude around the year 2045, ensuring the continued incentivization of miners to secure the network is of paramount importance. Ergo's architecture is designed to support a diverse range of revenue streams, promoting both network growth and long-term sustainability.

**Transaction Fees**

Transaction fees represent a crucial revenue source for miners. While currently modest in size, the potential for front-running transactions offers additional financial incentives. This cost can be adjusted by miners through on-chain voting, allowing for dynamic adjustments to align with network demands and market conditions.

**Storage Rent / 'Demurrage'**

The Storage Rent mechanism, also known as 'demurrage,' is already active and providing a small but steady income stream for miners. This innovative approach incentivizes the efficient use of blockchain storage by imposing a fee on unspent transaction outputs (UTXOs) that remain idle for an extended period. By validating transactions and managing the storage of UTXOs, miners play a vital role in maintaining the network's efficiency and earn rewards in the process. For more details, refer to the [Storage Rent](https://docs.ergoplatform.com/mining/rent/) page.

**Layer 2 Infrastructure**

Layer 2 (L2) solutions, such as state channels and sidechains, enhance scalability and improve transaction throughput on the Ergo blockchain. These solutions enable faster and more cost-effective transactions through off-chain processing. Miners can maintain and operate L2 infrastructure, ensuring the smooth functioning of these off-chain solutions and earning fees for their services. By supporting L2 infrastructure, miners contribute to the scalability and efficiency of the Ergo network, attracting more users and generating additional revenue opportunities.

Sigma Chains, with their support for various sidechain constructions, can serve as a robust foundation for Layer 2 solutions. Miners can leverage their expertise in securing Sigma Chains to provide and maintain L2 infrastructure, further diversifying their revenue streams.

**Sidechain Rewards**

Ergo's sidechain architecture provides a robust platform for developers to deploy their decentralized applications (dApps) and blockchain solutions. Miners can secure these sidechains and earn rewards for their contributions. By validating transactions and maintaining the security of sidechain operations, miners play a crucial role in the Ergo ecosystem and generate additional income.

A recent post on the forum, 'A[ Scalability Plan for Ergo](https://www.ergoforum.org/t/a-scalability-plan-for-ergo/226/5)', highlights the potential of sidechain rewards:

For incentivizing weak blocks reporting, they can commit to sidechains, thus making fast sidechains possible and miners will get rewards from that.

With the introduction of Sigma Chains, miners will have even more opportunities to secure and earn rewards from various sidechains. Sigma Chains offer different sidechain constructions, including merged-mined sidechains, double [merged-mined sidechains, and sidechains with dedicated mining algorithms](https://docs.ergoplatform.com/uses/sidechains/sigma-chains/#sidechain-constructions). By participating in the mining and security of these sidechains, miners can diversify their revenue streams and benefit from the growth of the Sigma Chain ecosystem.

**Adjusting the Re-emission Schedule**

As outlined in the paper "[Soft Power: Upgrading Chain Macroeconomic Policy Through Soft Forks](https://eprint.iacr.org/2021/577.pdf)", Ergo's emission schedule can be adjusted through on-chain voting and soft forks. This flexibility allows the Ergo community to re-evaluate and potentially extend the emission schedule if deemed necessary to ensure a smooth transition from mining rewards to the alternative revenue streams mentioned above. By opting to re-adjust the re-emission schedule, the community can maintain an optimal balance between mining incentives and the adoption of these new revenue mechanisms, ensuring the long-term sustainability of the Ergo network.

As Ergo continues to evolve and attract a broader user base, the potential for diverse and innovative revenue streams for miners will continue to expand. By actively engaging in these revenue-generating activities, miners not only secure the network but also contribute to the overall growth and success of Ergo and the Sigma Chain ecosystem. For more information on the Ergo Foundation's vision and plans for the future, please refer to the ../ef/ef-future.md page.

Note: Stay tuned for updates and announcements from the Ergo community regarding new and emerging revenue streams. These opportunities will be shared to enable miners to make informed decisions and maximize their earning potential.

Sustaining Ergo Mining: Revenue Streams Beyond Emissions

 Revenue 

## **GuapSwap**

Guapswap is a fully decentralized smart contract profit swapping service on the Ergo Blockchain.

[GitHub](https://github.com/GuapSwap)

[Project Report
](https://docs.ergoplatform.com/events/pdf/GuapSwap_-_ErgoHack3_Project_Report.pdf)

GuapSwap

## **Lithos**

Lithos is a project that aims to create a decentralized mining pool infrastructure by providing a low-risk opportunity for lenders to earn yield on their ERG by providing collateral to mining pools while promoting increasingly decentralized block production. This means that the project plans to enable miners to directly insert necessary transactions into blocks in a fully decentralized and trustless manner, bringing significant benefits to miners outside of just decentralization.

Traditionally, attempts to create decentralized mining pools have faced challenges such as security concerns, lack of miner usage, and failures to achieve both efficiency and full decentralization. However, Lithos proposes a new solution to these challenges by using a new protocol that verifies miners' work and pays them out accordingly while utilizing Stratum as the "networking layer" for the protocol. The protocol is blockchain-agnostic, meaning that Lithos may support mining pools for any Proof of Work (PoW) blockchain. Recently, Lithos has completed collateral contracts, and the ability of miners to directly insert necessary transactions into blocks has been successfully demonstrated during the ERGOHACK VI event. Overall, the goal of Lithos is to usher in a new era for PoW mining, where mining pools are fully decentralized, efficient, and trustless.

[Telegram](https://t.me/LITHOS_Protocol)

[GitHub](https://github.com/Lithos-Protocol)

[Litepaper](https://github.com/Lithos-Protocol/LitePaper)


Lithos

## **SNISP**

Succinct Non-Interactive Share Proofs (SNISPs) that will allow for accurate and efficient calculations of performed work on the blockchain. They use a combination of traditional shared calculation methods and concepts from NEPA Palace to compress the amount of work and the total set of shares that each miner creates, enabling the creation of efficient and decentralised mining pools. SNISPs incentivise miners to mine near their ideal top values, which they can commit to beforehand based on their hash rate and a stable value. This results in more secure and scalable mining pools with greater efficiency and decentralisation than traditional centralised mining pools.

These proofs are applicable to any Proof of Work blockchain and enable trustless calculation of work, which can be put on the blockchain. With SNISPs, decentralised mining pools can be created that have better security than P2Pool and scalability than ETH-based SmartPools. Furthermore, these proofs can be used for other applications that involve measuring performed work, such as direct work-based governance or work-backed assets. This means that SNISPs can potentially revolutionise how we approach work measurement and incentivisation in the blockchain space, providing a more efficient and trustworthy solution for various use cases.

![](https://media.discordapp.net/attachments/980490396356476938/1331586938674872340/image.png?ex=67922879&is=6790d6f9&hm=8c8e306cc20a959762552019d5b0045149b2c219d0293f8193c83a31f7b9d661&=&format=webp&quality=lossless&width=1165&height=716)

Please see the [LITHOS Protocol](https://docs.ergoplatform.com/eco/lithos/) for a continuation of this work.

[SNISP (Succint Non-Interactive Share Proofs) | Ergo Summit - Mining & Minting](https://www.youtube.com/watch?v=x-9x_PveRog)

SNISP

## **CYTI**

[CYTI](https://github.com/ThierryM1212/cyti) is the acronym for Choose Your Token ID. The team built a ‘minable’ smart contract that will allow an entity “to mint tokens with a given character sequence at the beginning of the token ID. A token minter creates a CYTI request, and miners generate the proper token ID using the CYTI miner software. When one of the miners succeeds, [they receive] the fee from the CYTI contract and the token with the right token ID is sent to the token minter.”

CYTI

## **Mining in Logarithmic Space**

Non-Interactive Proofs of Proof-of-Work (NIPoPoWs) allow smart contracts to retain historical data, enabling new light miners to operate in an online mode. This concept, known as Logarithmic Space Mining, allows for the compilation of unnecessary parts of the blockchain data into the blockchain itself. New miners don't need to carry historical data, and as they continue to mine, they assist other light miners in bootstrapping. This eliminates the need to carry old historical data, allowing old miners to discard historical data for lighter mining. This approach makes the entire miner population abandon old blocks, enhancing the system's efficiency.

This protocol is the first to achieve always secure, always succinct, and online Non-Interactive Proofs of Proof-of-Work, all necessary components for a logarithmic space mining scheme.

In this [video](https://www.youtube.com/watch?v=s05ypkSC7gk), Dionysis Zindros provides a detailed explanation of what Non-Interactive Proofs of Proof-of-Work truly are. He also evaluates the operation, implementation, and impact of this primitive.

**Overview**

Miners in Ergo, Bitcoin, or any other PoW consensus model must constantly maintain the blockchain. This not only uses computational resources but also storage resources to maintain all blockchain data from the genesis block.

A new miner might ask: Is it strictly necessary to download all the data from the genesis block? Why can't we download only the most relevant blocks to maintain the network?

The block headers of the blockchain should be sufficient to access the necessary data. [NIPoPoWs](https://nipopows.com/) can be integrated to form interlinked block header sets that will reduce historical data storage.

Miners should be able to efficiently access key blocks in the blockchain from the headers of the old blocks. Each new block must indicate all of the current networks. As new blocks are created, a set of new block headers can be enough to check for the current UTXO set. Since the new blocks contain the data of old stringed block header sets, it enables light mining by eliminating the need to download all the blockchain data.

**NIPoPoW Implementation**

Instead of accessing all of the blocks, superblocks (or light-clients) are enough to verify all of the blocks. This is accomplished by maintaining the historical data of the blockchain through smart contracts. The introduction of these superblock clients on NIPoPoWs can be done via 'velvet' or soft forks, and after that "light" miners can bootstrap through "online" mining.

Mining in Logarithmic Space

## **SmartPools: A Decentralized Mining Solution#**

SmartPools are a decentralized alternative to traditional mining pools. They replace centralized mining pools with autonomous on-chain smart contracts. The latest development in this area is the Lithos Protocol, which represents the next generation of SmartPools.

**The Concept of SmartPools**

The concept of SmartPools was first introduced at the ErgoHacks event. The idea was to replace centralized mining pools with an autonomous on-chain smart contract. A team of developers spent a weekend researching this concept and produced a whitepaper outlining their findings. This work was continued by another developer at ErgoHack II, who implemented the 'Sub Pooling' design specified in the SmartPools whitepaper.

**The Impact of SmartPools**

The introduction of SmartPools is a significant development in the world of mining. By replacing centralized mining pools with smart contracts, SmartPools can help reduce the risk of 51% attacks and other issues associated with centralization.

**Transparency in Mining Pool Fees**

In traditional mining pools, fees can vary between 1-3%, and miners can never be sure if they are getting their fair share. SmartPools aim to create transparency in this area, ensuring that miners' shares are distributed as earned. While the fees for using SmartPools may initially be around 1%, it is expected that these will be reduced to approximately 0.1% in the future to cover upkeep costs.

**The Risks of Centralization**

Centralization carries the risk of abuse, network halting, or double-spend attacks. As technology improves, the need to rely on centralized entities diminishes, making solutions like SmartPools increasingly important.

**The Problems SmartPools Aim to Solve**

SmartPools aim to address several issues associated with traditional mining pools:

`- Centralized mining pools charge high fees and it is not possible to verify the payments.
- Centralized mining pools pose a threat to network security as they control more shares in hash rate distribution.
- Solo miners require mining pools; otherwise, block finding times will be too long.
`

## The SmartPools Mining Model

**The SmartPools mining model offers several advantages:**

`- Mining pool contracts and reward schemes are verifiable and fair.
- Fees needed to maintain the server and fund the developers can be deducted on-chain.
- Decentralized mining models can prevent the manipulation of hash-power.
`

Ergo believes that SmartPools represent a necessary and essential step towards future decentralization. As we build the blockchain of the future, we hope to see as many facets of decentralization as possible.


## Resources

[What are smart pools?
](https://ergoplatform.org/en/blog/2021-11-19-ergo-smartpools-and-decentralized-mining/)

[Smart Pools](https://github.com/WilfordGrimley/ErgoSmartPools)

[SmartPools - the Future of PoW Mining](https://www.youtube.com/watch?v=pc3GEqMik48)

SmartPools: A Decentralized Mining Solution

## **Subpool**

Subpooling, a feature of [SmartPools](https://github.com/WilfordGrimley/ErgoSmartPools), is a decentralized mining solution that allows groups of miners to combine their hash rates for quicker mining rewards. This smart contract-based mining pool ensures that all members mine to the same address, eliminating the need for one person to control the funds.

The goal of Subpooling, and SmartPools in general, is to promote decentralization in mining pools and support small-scale miners who may struggle to earn block rewards quickly on traditional mining pools. By replacing centralized mining pools with autonomous on-chain smart contracts, SmartPools can help reduce the risk of 51% attacks and other issues associated with centralization.

The latest development in this area is the [Lithos Protocol,](https://docs.ergoplatform.com/eco/lithos/) which represents the next generation of SmartPools and further enhances the benefits of Subpooling.

This project was developed for [ERGOHACK II.](https://docs.ergoplatform.com/events/ergohack/)

Subpool

Tooling 

Ergo mining is based on Autolykos, an ASIC-resistant Proof of Work algorithm written in Scala.



Mining on Ergo

Course Details

Level

Ratings

Modules

Lessons

Holder $WORK Price

Contact Us

Documentation

Navigation