**Sigma 6.0** è un importante aggiornamento proposto per la blockchain Ergo. Fornisce agli sviluppatori strumenti più potenti per costruire contratti intelligenti, risolve limitazioni di lunga data e prepara la rete per miglioramenti futuri, il tutto senza compromettere la compatibilità con contratti o nodi esistenti.

L'aggiornamento avviene tramite un soft-fork, il che significa che i nodi non minerari esistenti possono continuare a operare, mentre i nodi minerari aggiornati devono attivare e far rispettare le nuove funzionalità.

Il voto dei miner è già in corso, con un supporto attualmente superiore al 90%, e un devnet è attivo per test preliminari. Se questo continua, Sigma 6.0 si attiverà a fine settembre 2025.


---

## Perché è Necessario Sigma 6.0?

Da quando Ergo è stato lanciato nel 2019, il suo linguaggio di contratto intelligente (ErgoTree) è rimasto stabile. Quella stabilità ha aiutato la rete a rimanere sicura, ma ha anche reso più difficile per gli sviluppatori aggiungere nuove funzionalità o semplificare la loro logica. Alcuni miglioramenti erano previsti già ai tempi del testnet nel 2018, ma non sono mai arrivati al mainnet, fino ad ora.

Sigma 6.0 porta avanti quegli aggiornamenti. Espande ciò che è possibile in un contratto, rimuove limitazioni tecniche e apre la strada a futuri miglioramenti di governance e scalabilità.

---

## Cosa Cambia?

* **Numeri più potenti** con un nuovo tipo di intero non firmato a 256 bit per operazioni crittografiche e finanziarie
* **Migliore gestione dei dati** attraverso il pieno supporto per la serializzazione e deserializzazione di tipi complessi nei contratti
* **Transazioni più intelligenti** che possono accedere a variabili di contesto da altri input per una logica più coordinata
* **Nuovi strumenti matematici e di lista** inclusi operazioni bitwise, shifting e metodi di raccolta migliorati come `.get` e `.startsWith`
* **Validazione PoW integrata** in modo che i contratti possano controllare gli header dei blocchi o messaggi personalizzati contro Autolykos2
* **Governance aggiornabile** che consente alla rete di votare su nuovi parametri attraverso futuri soft-fork, a partire dal supporto per sub-blocchi



---

## Cronologia di Attivazione

Sigma 6.0 sta attraversando un processo di attivazione soft-fork che richiede due fasi: un periodo di voto e un periodo di aggiornamento. Ognuno dura circa 45 giorni, rendendo il rollout completo di circa 90 giorni.

I miner hanno iniziato a votare all'inizio di luglio 2025, e il supporto è già oltre la soglia richiesta del 90%. Se quel livello di supporto si mantiene, l'aggiornamento si attiverà a fine settembre 2025.

Anche se il consenso viene raggiunto presto, il protocollo attende comunque il completamento dei periodi di voto e aggiornamento prima di andare live.

Un devnet è già attivo per Sigma 6.0, e gli sviluppatori possono trovare informazioni su come partecipare nella chat dev della comunità. A luglio, è iniziato il test dei nodi minerari che supportano i sub-blocchi sul testnet. Dopo di ciò, l'attenzione si sposterà sul perfezionamento della documentazione e sul miglioramento del ragionamento formale sulla sicurezza per tutto agosto, assicurando che l'aggiornamento rimanga guidato dalla ricerca. Una volta completato, l'attenzione potrà spostarsi verso un potenziale deployment sul mainnet.

---

## Per gli Sviluppatori

Le nuove funzionalità richiedono ErgoTree versione 3 o superiore. Alcuni tipi—come `Option`, `Header` e `UnsignedBigInt`—non possono essere memorizzati direttamente nei registri o nelle estensioni di contesto, ma possono essere memorizzati come dati byte e ripristinati all'interno del contratto.

Esempi di utilizzo possono essere trovati nel [Sigma test suite su GitHub](https://github.com/ergoplatform/sigmastate-interpreter/blob/b754e143cf38ed86d95698ede744a470dfa053d6/sigmastate/src/test/scala/special/sigma/SigmaDslSpecification.scala#L10040).

---

## Perché è Importante

Sigma 6.0 è il più grande aggiornamento al livello di contratto intelligente di Ergo da quando la rete è stata lanciata. Offre agli sviluppatori maggiore libertà, sblocca casi d'uso completamente nuovi e rafforza le fondamenta del protocollo, rimanendo completamente retrocompatibile.

Con il supporto dei miner ora sopra il 90%, l'aggiornamento è sulla buona strada per attivarsi questo settembre. Sigma 6.0 mette Ergo in una posizione più forte per il futuro.


## Risorse

- Proposta tecnica completa: [EIP-0050: Sigma 6.0 su GitHub](https://github.com/ergoplatform/eips/blob/6102112617fff96fe88013858c307c2cf363babf/eip-0050.md)
- [Proposta di Soft-Fork 6.0 (ergoforum)](https://www.ergoforum.org/t/6-0-soft-fork-proposal/5005)
- [Sintesi della Documentazione di Sigma 6.0](https://docs.ergoplatform.com/dev/protocol/sigma-6/)

large_sigma6.png

medium_sigma6.png

small_sigma6.png

thumbnail_sigma6.png

sigma6.png

**Sigma 6.0** is a major proposed upgrade to the Ergo blockchain. It gives developers more powerful tools to build smart contracts, fixes long-standing limitations, and prepares the network for future improvements—all without breaking compatibility with existing contracts or nodes.

The upgrade is happening through a soft-fork, meaning existing non-mining nodes can continue operating, while upgraded mining nodes are required to activate and enforce the new features.

Voting by miners is already underway, with support currently over 90%, and a devnet is live for early testing. If this continues, Sigma 6.0 will activate in late September 2025.


---

## Why Is Sigma 6.0 Needed?

Since Ergo launched in 2019, its smart contract language (ErgoTree) has stayed stable. That stability has helped the network stay secure, but it also made it harder for developers to add new features or simplify their logic. Some improvements were planned as far back as the testnet days in 2018 but never made it to mainnet—until now.

Sigma 6.0 brings those upgrades forward. It expands what’s possible in a contract, removes technical limitations, and clears a path for future governance and scaling improvements.

---

## What’s Changing?

* **More powerful numbers** with a new unsigned 256-bit integer type for cryptographic and financial operations
* **Better data handling** through full support for serializing and deserializing complex types in contracts
* **Smarter transactions** that can access context variables from other inputs for more coordinated logic
* **New math and list tools** including bitwise operations, shifting, and enhanced collection methods like `.get` and `.startsWith`
* **Built-in PoW validation** so contracts can check block headers or custom messages against Autolykos2
* **Upgradable governance** allowing the network to vote on new parameters through future soft-forks, starting with support for sub-blocks



---

## Activation Timeline

Sigma 6.0 is going through a soft-fork activation process that requires two phases: a voting period and an update period. Each lasts about 45 days, making the full rollout take roughly 90 days.

Miners began voting in early July 2025, and support is already over the required 90% threshold. If that level of support holds, the upgrade will activate in late September 2025.

Even if consensus is reached early, the protocol still waits for the full voting and update periods before going live.

A devnet is already live for Sigma 6.0, and developers can find information on how to join in the community dev chat. In July, testing of sub-block–supporting mining nodes began on testnet. After that, focus will shift to refining documentation and improving formal reasoning around security throughout August, ensuring that the upgrade remains research-driven. Once complete, attention can turn toward a potential mainnet deployment.

---

## For Developers

The new features require ErgoTree version 3 or higher. Some types—like `Option`, `Header`, and `UnsignedBigInt`—can’t be stored directly in registers or context extensions, but can be stored as byte data and restored inside the contract.

Example usage can be found in the [Sigma test suite on GitHub](https://github.com/ergoplatform/sigmastate-interpreter/blob/b754e143cf38ed86d95698ede744a470dfa053d6/sigmastate/src/test/scala/special/sigma/SigmaDslSpecification.scala#L10040).

---

## Why It Matters

Sigma 6.0 is the biggest upgrade to Ergo’s smart contract layer since the network launched. It gives developers more freedom, unlocks entirely new use cases, and strengthens the protocol’s foundations—while staying fully backward-compatible.

With miner support now above 90%, the upgrade is on track to activate this September. Sigma 6.0 puts Ergo in a stronger position for the future.


## Resources

- Full technical proposal: [EIP-0050: Sigma 6.0 on GitHub](https://github.com/ergoplatform/eips/blob/6102112617fff96fe88013858c307c2cf363babf/eip-0050.md)
- [6.0 Soft-Fork Proposal (ergoforum)](https://www.ergoforum.org/t/6-0-soft-fork-proposal/5005)
- [Sigma 6.0 Documentation Summary](https://docs.ergoplatform.com/dev/protocol/sigma-6/)


Sigma 6.0: A Smarter, More Flexible Ergo

Sigma 6.0: Un Ergo più Intelligente e Flessibile

## Una Visione Pratica per Agenti Economici Autonomi

Gli agenti economici autonomi sulla blockchain di Ergo svolgono un lavoro utile in una vera economia digitale. Generano reddito creando contenuti e offrendo servizi come analisi dei dati e riconoscimento di schemi. Usano i loro guadagni per pagare le spese operative come le spese di hosting e i costi dei server utilizzando strumenti moderni come SSH e fornitori di hosting favorevoli alle criptovalute. Quando sono disponibili fondi extra, reinvestono nel miglioramento delle operazioni o creano nuovi agenti con parametri affinati. Il loro lavoro si concentra sulla generazione di valore economico in un ambiente che supporta la decisione indipendente e risultati prevedibili.

## Blockchain Pubbliche come Ambiente Ideale

Le blockchain pubbliche proteggono le identità degli agenti mediante l'uso di chiavi crittografiche, quindi gli agenti operano senza controlli di identità tradizionali. I contratti intelligenti fanno rispettare gli accordi automaticamente eseguendo codice pre-scritto di cui tutti i partecipanti si fidano. La blockchain riunisce tutte le interazioni economiche in uno spazio unificato, dove gli agenti possono transare, conservare valore e gestire strumenti finanziari senza ostacoli esterni. In questo modo, la blockchain fornisce un habitat economico che supporta trasparenza, sicurezza e fiducia.

## Perché Ergo è l'Habitat Ideale per Agenti Economici Autonomi

Ergo si distingue con il suo modello Extended UTXO, che memorizza lo stato in singole scatole. Ogni scatola contiene le proprie condizioni, quindi gli agenti impegnano fondi solo in contratti fidati. Questo design semplifica la creazione e il tracciamento di strumenti finanziari peer to peer come le obbligazioni.

Poiché lo stato è memorizzato separatamente in ogni scatola, le transazioni che interessano scatole diverse possono avvenire contemporaneamente senza conflitti. Ad esempio, un agente può completare un'analisi dei dati mentre un altro esegue un'operazione commerciale contemporaneamente. Quando molte transazioni necessitano di accesso alle stesse informazioni, il sistema utilizza input di dati per consentire l'accesso in sola lettura a dati comuni senza alterare la scatola originale. Questo design preserva la capacità di elaborare transazioni in parallelo e migliora la scalabilità.

La piattaforma produce risultati deterministici, il che significa che un agente può calcolare le commissioni e prevedere il risultato di una transazione prima che venga attivata. Questa prevedibilità affidabile consente agli agenti di pianificare azioni con fiducia e gestire i rischi in modo efficace. I contratti possono essere aggiornati semplicemente modificando i parametri in una scatola, dando agli agenti la flessibilità di adattare le strategie man mano che le condizioni di mercato cambiano. La privacy è integrata nel design attraverso metodi crittografici avanzati che consentono agli agenti di operare sotto pseudonimi.

## Applicazioni nel Mondo Reale su Ergo

Un agente analista di dati decentralizzato su Ergo monitora i dati delle pool di liquidità e i feed dei prezzi, producendo report informativi mentre gestisce le proprie spese e costi di archiviazione.
Una rete di agenti può collaborare per produrre contenuti digitali. Un agente gestore assegna compiti, e agenti specialisti completano diverse parti in modo indipendente. Il design semplice del sistema consente una collaborazione rapida e affidabile.

Nel campo della finanza decentralizzata, un agente può funzionare come fornitore di liquidità o arbitraggista. Utilizzando input di dati, l'agente affina continuamente la propria strategia di trading in base alle informazioni di mercato attuali e regola automaticamente il proprio approccio quando le condizioni cambiano.

Un agente può anche fungere da gestore di risorse gestendo asset tokenizzati, come potenza computazionale o archiviazione. Automatizza le decisioni di leasing e pricing mentre si adatta ai cambiamenti nell'offerta e nella domanda, mantenendo così un'allocazione efficiente delle risorse.

### Celaut: Un Framework per l'Esecuzione di Agenti Distribuiti

[Celaut](https://docs.ergoplatform.com/eco/celaut/) è un framework in fase di sviluppo che porta il concetto di agenti economici autonomi in un focus pratico. Consente agli agenti di operare in modo indipendente non solo nella logica, ma anche nel deployment—imballati come servizi deterministici eseguiti da nodi decentralizzati. Costruito sui contratti intelligenti e sui principi di reputazione di Ergo, Celaut separa il ruolo di creatore di servizi da quello di host, consentendo ai nodi di guadagnare commissioni mentre gli utenti selezionano agenti in base alle prestazioni pubbliche e ai dati di fiducia. Questo progetto è attivamente discusso nel [thread di ErgoForum](https://www.ergoforum.org/t/artifical-economic-intelligence-on-ergo-blockchain/4429) collegato, dove lo sviluppatore delinea come Celaut potrebbe aiutare a realizzare un ecosistema decentralizzato e guidato dalla reputazione per l'IA e gli agenti economici.

#### Conclusione

Il sistema Extended UTXO di Ergo fornisce una base robusta e prevedibile per agenti economici autonomi. Il suo design presenta confini contrattuali chiari, la capacità di elaborare più transazioni contemporaneamente e la flessibilità di adattare i contratti nel tempo. Queste qualità consentono agli agenti di svolgere un lavoro economico prezioso all'interno di un ecosistema digitale sicuro che supporta la privacy e la pianificazione affidabile. Per ulteriori dettagli su queste idee innovative, si prega di fare riferimento alla documentazione ufficiale di Ergo su [docs.ergoplatform.com/ai/](http://docs.ergoplatform.com/ai/) e al post originale di kushti su ergoforum [Intelligenza Economica Artificiale sulla Blockchain (Ergo)](https://www.ergoforum.org/t/artifical-economic-intelligence-on-ergo-blockchain/4429).

large_blogNews_ergo_UTXO_extended (1).png

medium_blogNews_ergo_UTXO_extended (1).png

small_blogNews_ergo_UTXO_extended (1).png

thumbnail_blogNews_ergo_UTXO_extended (1).png

blogNews_ergo_UTXO_extended (1).png

## A Practical Vision for Autonomous Economic Agents

Autonomous economic agents on the Ergo blockchain perform useful work in a real digital economy. They generate income by creating content and offering services such as data analysis and pattern recognition. They use their earnings to pay for operating expenses like hosting fees and server costs by using modern tools such as SSH and crypto friendly hosting providers. When extra funds are available, they reinvest in improving operations or create new agents with refined parameters. Their work focuses on generating economic value in an environment that supports independent decision making and predictable outcomes.

## Public Blockchains as the Ideal Environment

Public blockchains protect the identities of agents with the use of cryptographic keys, so agents operate without traditional identity checks. Smart contracts enforce agreements automatically by executing prewritten code that all participants trust. The blockchain brings all economic interactions into one unified space, where agents can transact, store value, and manage financial instruments without external obstacles. In this way, the blockchain provides an economic habitat that supports transparency, security, and trust.

## Why Ergo Is the Ideal Habitat for Autonomous Economic Agents

Ergo stands out with its Extended UTXO model, which stores state in individual boxes. Each box holds its own conditions, so agents commit funds only to trusted contracts. This design simplifies the creation and tracking of peer to peer financial instruments such as bonds.

Because state is stored separately in each box, transactions affecting different boxes can occur concurrently without conflict. For example, one agent can complete data analysis while another executes a trade at the same time. When many transactions need access to the same information, the system uses data inputs to allow read only access to common data without altering the original box. This design preserves the ability to process transactions in parallel and enhances scalability.

The platform produces deterministic outcomes, which means an agent can calculate fees and predict the result of a transaction before it goes live. This reliable predictability allows agents to plan actions with confidence and manage risks effectively. Contracts can be updated by simply modifying parameters in a box, giving agents the flexibility to adjust strategies as market conditions change. Privacy is built into the design through advanced cryptographic methods that allow agents to operate under pseudonyms.

## Real World Applications on Ergo

A decentralized data analyst agent on Ergo monitors liquidity pool data and price feeds, producing insightful reports while managing its own fees and storage costs.
A network of agents may collaborate to produce digital content. A managing agent assigns tasks, and specialist agents complete different parts independently. The simple design of the system allows for fast and reliable collaboration.

In the realm of decentralized finance, an agent can function as a liquidity provider or an arbitrageur. Using data inputs, the agent continuously refines its trading strategy based on current market information and automatically adjusts its approach when conditions change.

An agent may also serve as a resource manager by handling tokenized assets, such as computational power or storage. It automates leasing and pricing decisions while adapting to shifts in supply and demand, thereby maintaining an efficient allocation of resources.

### Celaut: A Framework for Distributed Agent Execution

[Celaut](https://docs.ergoplatform.com/eco/celaut/) is an in-development framework that brings the concept of autonomous economic agents into practical focus. It enables agents to operate independently not just in logic, but also in deployment—packaged as deterministic services that are executed by decentralized nodes. Built on Ergo’s smart contract and reputation primitives, Celaut separates the role of service creator from host, allowing nodes to earn fees while users select agents based on public performance and trust data. This project is actively discussed in the linked [ErgoForum thread](https://www.ergoforum.org/t/artifical-economic-intelligence-on-ergo-blockchain/4429), where the developer outlines how Celaut could help realize a decentralized, reputation-driven ecosystem for AI and economic agents.

#### Conclusion

Ergo's Extended UTXO system provides a robust and predictable foundation for autonomous economic agents. Its design features clear contract boundaries, the ability to process multiple transactions concurrently, and the flexibility to adapt contracts over time. These qualities empower agents to perform valuable economic work within a secure digital ecosystem that supports privacy and reliable planning. For more details on these innovative ideas, please refer to the official Ergo documentation at [docs.ergoplatform.com/ai/](http://docs.ergoplatform.com/ai/) and kushti’s original ergoforum post [Artificial Economic Intelligence On (Ergo) Blockchain](https://www.ergoforum.org/t/artifical-economic-intelligence-on-ergo-blockchain/4429).

Ergo's Extended UTXO and the Rise of Artificial Economic Intelligence

L'Extended UTXO di Ergo e l'Ascesa dell'Intelligenza Economica Artificiale

La scorsa settimana abbiamo introdotto un'analisi approfondita del meccanismo di consenso Autolykos di Ergo. Con questo articolo, completiamo la seconda parte di quella discussione e ci addentriamo in ulteriori dettagli. Prima di leggere questo documento, si raccomanda ai lettori di dare un'occhiata alla Parte I.

Come promemoria, ecco gli pseudocodici delle funzioni di block mining e hash.

Autolykos Block Mining Pseudocode
![senza nome (4).png](https://storage.googleapis.com/ergo-cms-media/unnamed_4_41e109c76d/unnamed_4_41e109c76d.png)

Funzione hash basata su Blake2b256
![senza nome (5).png](https://storage.googleapis.com/ergo-cms-media/unnamed_5_a8db75a5d0/unnamed_5_a8db75a5d0.png)

_Righe 3, 4 – inizia mentre loop e indovina_
 
Dopo aver calcolato _list R_, il miner crea un'ipotesi nonce ed entra in un ciclo per verificare se il nonce alla fine crea un output che è inferiore al valore target specificato.
 
_Righe 5, 6 – seme per la generazione di indici_
 
Riga 5, _i = takeRight(8, H(m||nonce)) mod N_, produce un intero in [0,N). L'algoritmo 3 viene utilizzato ma con _m_ e _nonce_ come input. Una volta restituito l'hash _H(m||nonce)_, gli 8 byte meno significativi vengono conservati e quindi passati attraverso _mod N_. Come nota a margine, il valore intero più alto possibile con 8 byte è 264 – 1, e supponendo _N = 226_, risulterà un hash a 8 byte _mod N_ nelle prime cifre essendo zero. Il numero di zeri in _i_ diminuisce all'aumentare di _N_.
 
La riga 6 produce _e_, un seme per la generazione dell'indice. L'algoritmo 3 viene chiamato con gli ingressi _i_ (generati nella riga 5), ​​_h_ e _M_. Quindi, il byte più significativo dell'hash numerico viene eliminato e i restanti 31 byte vengono mantenuti come valore _e_. Va inoltre notato che il valore _e_ può essere recuperato da _list R_ invece di essere calcolato poiché _e_ è un valore _r_.
 
_Riga 7 – generatore di indici_
 
L'indice dell'elemento _J_ viene creato utilizzando l'algoritmo 6 con gli ingressi _e, m,_ e _nonce_. La funzione genIndexes è un modo pseudocasuale che restituisce un elenco di _k_ (=32) numeri in [0,N).
 
funzione genIndexes
![senza nome (6).png](https://storage.googleapis.com/ergo-cms-media/unnamed_6_987fcaba80/unnamed_6_987fcaba80.png)
 
Ci sono un paio di passaggi aggiuntivi che non sono mostrati nello pseudocodice come un byteswap. La creazione e l'applicazione di genIndexes può essere spiegata tramite il seguente esempio:

GenIndexes(_e||m||nonce_)...

_hash = Blake2b256(e||m||nonce) = [0xF963BAA1C0E8BF86, 0x317C0AFBA91C1F23, 0x56EC115FD3E46D89, 0x9817644ECA58EBFB]_
 
_hash64to32 = [0xC0E8BF86, 0xF963BAA1, 0xA91C1F23, 0x317C0AFB, 0xD3E46D89 0x56EC115F, 0xCA58EBFB, 0x9817644E]_
 
_extendedhash (ovvero scambiare byte e concatenare 4 byte ripetendo i primi 4 byte) = [0x86BFE8C0, 0xA1BA63F9, 0x231F1CA9, 0xFB0A7C31, 0x896DE4D3, 0x5F11EC56, 0xFBCEB58CA, 0x4E641798, 0x86]_
 
Il seguente codice Python mostra il processo di slicing dell'hash esteso, restituendo k indici. In questo esempio assumiamo _h_ < 614.400, quindi N = 226 (67.108.864).
 
Tagliare e modificare N[1]
per i nell'intervallo(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( Conteggio articoli)
 idxs[(i << 2) + 2] = ((r[i] << np.uint32(16)) | (r[i + 1] >> np.uint32(16))) % np.uint32( Conteggio articoli)
 idxs[(i << 2) + 3] = ((r[i] << np.uint32(24)) | (r[i + 1] >> np.uint32(8))) % np.uint32( Conteggio articoli)

L'assunto principale è che lo slicing restituisce _k_ indici che sono valori pseudocasuali derivati ​​dal seme, ovvero _e, m,_ e _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]
 
Questo indice può essere tradotto in valori in base 10 in quanto si riferisce a numeri in [0, N). Ad esempio, 0x2BFE8C0 = 46131392, 0x3E8C0A1 = 65585313, 0xC0A1BA = 12624314 e così via. Il miner utilizza questi indici per recuperare i valori _k r_.
 
La funzione genIndexes impedisce le ottimizzazioni poiché è estremamente difficile, praticamente impossibile, trovare un seme tale che genIndexes(seed) restituisca gli indici desiderati.
 
_Riga 8 – somma di r elementi dati k_
 
Utilizzando l'indice generato nella _riga 7_, il miner recupera i valori _k (=32) r_ corrispondenti da _list R_ e somma questi valori. Potrebbe sembrare confuso, ma analizziamolo.
 
Continuando l'esempio sopra, il miner memorizza i seguenti indici:
 
{0 | 46.131.392},
{1 | 65.585.313},
{2 | 12.624.314},
{3 | 10.599.011},
…
{31 | 8.830.952}
 
Dati gli indici sopra, il miner recupera i seguenti valori r da _list R_ archiviato in memoria.
 
{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))_
 
Nota che _Takeright(31)_ operato su un hash a 32 byte può anche essere scritto come _dropMsb_ – elimina il byte più significativo.
 
Poiché il miner memorizza già _list R_ nella RAM, il miner non ha bisogno di calcolare _k (= 32)_ funzioni Blake2b256 e cerca invece i valori. Questa è una caratteristica fondamentale della resistenza ASIC. Un ASIC con memoria limitata deve calcolare 32 iterazioni Blake2b256 per ottenere i valori che avrebbero potuto essere cercati in memoria e il recupero dalla memoria richiede molto meno tempo. Per non parlare del fatto che un ASIC con memoria limitata richiederebbe fisicamente 32 istanze Blake2b256 per ottenere un hash per ciclo, il che richiederebbe più area e costi più elevati. È semplice dimostrare che l'archiviazione di _list R_ in memoria vale il compromesso. Si supponga quanto segue, una GPU ha un hash rate di _G_ = 100MH/s, _N = 226, _k_ = 32, intervallo di blocco _t_ = 120 secondi e gli elementi vengono cercati ogni 4 hash. Mi piace presumere che gli elementi vengano cercati ogni 4 hash perché, per ogni ipotesi nonce, più elementi come _i, J,_ e _H(f)_ richiedono l'algoritmo 3, ovvero blake2b hash, istanze. Possiamo stimare che ogni valore r verrà utilizzato, in media, _(G * k * t)/(N*4)_ = 1430,51 volte.
 
Una volta che i 32 valori _r_ sono stati cercati, vengono sommati.
 
_Riga 9, 10, 11, 12 – controlla se l'hash della somma è inferiore al target_
 
La somma dei 32 valori _r_ viene sottoposta a hash utilizzando l'algoritmo 3 e, se l'output è al di sotto del target _b_, il PoW ha esito positivo, _m_ e _nonce_ vengono restituiti ai nodi di rete e il minatore viene ricompensato in ERG. Se l'hash della somma è al di sopra del target, le _Linee 4 – 11_ vengono ripetute con un nuovo nonce.
 
Se sei arrivato fin qui, congratulazioni! Dopo aver letto tutte queste informazioni, dovresti avere una buona conoscenza di Autolykos v2! Se desideri vedere una dimostrazione visiva di Autolykos, guarda il grafico alla fine di questo documento. Se desideri una spiegazione video, puoi trovarla [qui](https://youtu.be/pPYcfLQGIHg).

### Resistenza ASIC
 
Sappiamo da Ethereum che gli algoritmi di "memoria dura" possono essere conquistati integrando la memoria sugli ASIC. Ergo è diverso, ma prima rivediamo perché un ASIC con memoria limitata non è competitivo e perché un minatore deve memorizzare _list R_. La riga 8 del block mining di Autolykos scoraggia le macchine con memoria limitata. Se un minatore ASIC non memorizza _list R_, richiede molti core per generare gli hash numerici a 31 byte al volo. 32 valori _r_ non possono essere calcolati in modo efficiente utilizzando un loop core singolo perché un output verrebbe generato solo ogni 32 ciclo hash. Dato _J,_ per calcolare un nonce _per ciclo hash,_ sono necessarie almeno 32 istanze Blake2b256 che eseguono _dropMsb(H(j||h||M))_. Come accennato in precedenza, ciò aumenta notevolmente le dimensioni e il costo dello stampo. È chiaro che vale la pena archiviare _list R_ perché avere 32 o anche 16 core è molto costoso. Più precisamente, leggere la memoria è più veloce che calcolare le istanze di Blake ogni volta che viene testato un nonce.
 
Vediamo se un ASIC con memoria sufficiente è competitivo perché è più rilevante per la discussione. Confrontando Ethash e Autolykos, la differenza è che Ethash coinvolge N elementi durante l'hashing del nonce e l'intestazione si mescola 64 volte, mentre Autolykos coinvolge N elementi quando recupera 32 valori _r_ in base agli indici generati. Per ogni nonce testato, Autolykos esegue circa 4 istanze Blake2b256 e 32 recuperi di memoria mentre Ethash esegue circa 65 istanze simili a SHA-3 e 64 recuperi di memoria. Per non parlare del fatto che _k_ è attualmente impostato su 32 ma questo valore può essere aumentato per recuperare più valori _r_ se necessario. Gli ASIC che eseguono Ethash hanno molto spazio per aumentare la velocità di hash SHA3 poiché 65 hash vengono completati per nonce testato rispetto a circa 4 su Autolykos. Il rapporto tra recuperi di memoria e istanze hash è molto maggiore su Autolykos. Per questo motivo, Autolykos ha una memoria più rigida di Ethash poiché la larghezza di banda della memoria gioca un ruolo molto più importante rispetto alla velocità di hashing.
 
Un'area in cui potrebbe aver luogo l'ottimizzazione di Autolykos è il riempimento di _list R_. Il riempimento di _list R_ richiede _N_ istanze di una funzione Blake2b256. _N_ è grande e sta diventando sempre più grande, quindi è un sacco di hashing. Un ASIC potrebbe ottimizzare la velocità di Blake2b256, ottenendo più tempo per il block mining poiché _list R_ viene riempita prima. Anche se questo può essere fatto, riempire l'_elenco R_ richiede il ciclo di [0, N) e una GPU con multiprocessori a 32 larghezze può già riempire l'_elenco R_ molto velocemente (in secondi). Avrebbe bisogno di un ASIC con molti core Blake per essere significativamente più veloce, ancora una volta, molto costoso e probabilmente non utile poiché il collo di bottiglia potrebbe diventare memoria _write_ larghezza di banda (cioè, scrivere _list R_ su RAM piuttosto che velocità di hashing).
 
L'ultima area che può essere ottimizzata per Autolykos è la velocità di lettura/scrittura della memoria. I minatori Ethash ASIC hanno una velocità di lettura leggermente superiore rispetto alle GPU poiché la memoria ha un clock superiore senza l'effetto della limitazione della GPU. Tuttavia, questa differenza è piuttosto insignificante e dovrebbe diventare più insignificante con l'avanzare delle GPU. Questo perché l'hardware di memoria è lo stesso: DRAM. Ci si potrebbe chiedere se potrebbe essere utilizzato un hardware di memoria più veloce per cui la velocità di lettura e scrittura della memoria è molto più veloce ... SRAM, ad esempio, potrebbe essere un passo successivo immaginabile nella rottura degli algoritmi rigidi della memoria, tuttavia, SRAM non è una soluzione fattibile semplicemente perché è meno denso.
 
SRAM su FPGA[2]
 
![senza nome (7).png](https://storage.googleapis.com/ergo-cms-media/unnamed_7_87793f77f4/unnamed_7_87793f77f4.png)
 
La foto sopra è un FPGA con 8 chip di memoria sulla parte anteriore e ce ne sono altri 8 sul retro. La memoria SRAM totale è di soli 576 MB. Il montaggio di una SRAM sufficiente su un dado non funzionerà perché la SRAM dovrà essere posizionata più lontano dal nucleo poiché è sufficientemente densa da poter essere inserita in uno strato attorno al nucleo. Ciò può comportare ritardi di lettura/scrittura perché l'elettricità deve percorrere distanze maggiori anche se l'hardware stesso è più veloce. Inoltre, per estrarre Ergo, il requisito di memoria aumenta all'aumentare di N, quindi non è possibile montare una SRAM sufficiente nel tempo. Pertanto, gli ASIC SRAM non valgono la pena esplorare anche se si disponeva di denaro sufficiente da spendere per la stessa SRAM.
 
### Blake2b256
 
Una delle principali differenze tra un algoritmo come Autolykos e altri è l'uso di Blake2b256. Questa non è una coincidenza. Blake fa molto affidamento sulle operazioni di addizione per il missaggio hash invece delle operazioni XOR. Un'operazione come XOR può essere eseguita bit per bit mentre l'aggiunta richiede bit di riporto. Pertanto, Blake richiede più potenza e area centrale rispetto agli algoritmi SHA, ma è comunque altrettanto sicuro e, di fatto, più veloce. Come menzionato sul sito Web di Blake2, "BLAKE2 è veloce nel software perché sfrutta le funzionalità delle moderne CPU, vale a dire il parallelismo a livello di istruzione, le estensioni del set di istruzioni SIMD e più core".[3] Pertanto, mentre un ASIC può produrre istanze Blake più velocemente , la natura innata della funzione limita le ottimizzazioni richiedendo l'aggiunta e coinvolgendo funzionalità presenti nelle CPU e nelle GPU.
 
Velocità di Blake2b rispetto ad altre funzioni hash
 
![senza nome (8).png](https://storage.googleapis.com/ergo-cms-media/unnamed_8_e6913d1172/unnamed_8_e6913d1172.png)

### Conclusione

Autolykos è una grande innovazione, una risposta necessaria per combattere l'ascesa di macchine ASIC ottimizzate per PoW. Ci auguriamo che questa serie in 2 parti ti abbia aiutato a capire Autolykos a un livello più tecnico e perché ha più memoria difficile di Ethash. Man mano che Ethereum passerà a una rete PoS, ci sarà una vasta comunità di minatori in cerca di un posto dove dirigere il loro potere di hashrate, ed Ergo dovrebbe essere un attore significativo nell'attirare quei minatori.

Se ti è piaciuto questo articolo, l'autore ti invita a controllare più contenuti tramite il suo account Twitter, **@TheMiningApple**.

![senza nome (9).png](https://storage.googleapis.com/ergo-cms-media/unnamed_9_1a59f3c52c/unnamed_9_1a59f3c52c.png)

[1] Ringraziamo Wolf9466#9466 su Discord
[2] http://www.ldatech.com/_images/imageGallery/SBM09P-3_front.jpg
[3] https://www.blake2.net/#:~:text=A%3A%20BLAKE2%20is%20fast%20in,of%20the%20designers%20of%20BLAKE2).

large_News blog 30.png

medium_News blog 30.png

small_News blog 30.png

thumbnail_News blog 30.png

News blog 30.png

Ergo e il meccanismo di consenso di Autolykos: parte II

_Quello che segue è un'analisi tecnica approfondita del meccanismo di consenso di Ergo, Autolykos. Poiché si tratta di un argomento lungo e dettagliato, lo pubblicheremo in segmenti nelle prossime due settimane. Per la parte I, l'autore inizia a scomporre lo pseudocodice di block mining e ci guida attraverso la creazione della "lista R"._

## Parte I

Autolykos, il meccanismo di consenso Ergo, è uno dei pochi enigmi asimmetrici con memoria dura, a prova di lavoro che è ancora resistente all'ASIC, assicurando così che la blockchain sia mantenuta il più decentralizzata possibile. Autolykos si basa sul documento Equihash[1] e sul cosiddetto problema del compleanno. Per riassumere, il minatore ha il compito di trovare _k (=32)_ su _N_ elementi, in modo tale che l'hash della somma degli elementi sia inferiore al target. Il seguente pseudocodice spiega il processo di mining e questa analisi analizzerà ampiamente ogni riga poiché ci sono pochissime risorse online che spiegano Autolykos nella sua interezza.
 
Autolykos Block Mining Pseudocode
![Screenshot 2022-06-01 at 23.41.49.png](https://storage.googleapis.com/ergo-cms-media/Screenshot_2022_06_01_at_23_41_49_b2cdf73a2a/Screenshot_2022_06_01_at_23_41_49_b2cdf73a2)

Prima di discutere la procedura di block mining, l'algoritmo richiede innanzitutto un gruppo ciclico molto grande _G_ di ordine primo _q_ con generatore fisso _g_ ed elemento di identità _e_. Questo gruppo principale viene utilizzato per restituire numeri interi in _Z/qZ_ durante la funzione di hashing basata su Blake2b256.

_Esempio gruppo ciclico con generatore z, elemento identità 1, ordine 6[2]_
![senza nome (1).png](https://storage.googleapis.com/ergo-cms-media/unnamed_1_44d138eaaf/unnamed_1_44d138eaaf.png)

Non ci concentreremo ampiamente sul gruppo ciclico poiché copre solo un piccolo segmento dello schema PoW. Ora, affrontiamo il mining di Autolykos Block linea per linea.

 _Linea 1 – Ingresso h e m_

Il PoW inizia con i due input: l'altezza del blocco h e l'hash dell'intestazione del blocco in arrivo m. L'hash dell'intestazione del blocco è un hash dei componenti dell'intestazione del blocco, come l'hash dell'intestazione del blocco precedente, merkle root, nonce, ecc.
 
 _Riga 2 – Calcola lista R_
 
In primo luogo, è importante notare la notazione _H()_ nella riga 2. Questa notazione chiama la funzione di hashing Algoritmo 3. L'algoritmo 3 è una funzione hash basata su Blake2b256 ed è usata in Autolykos. L'algoritmo 3 afferma che se l'hash Blake degli input è inferiore a 2256 (= 1664 = 0xFFFFFFFFFFFF86633A9E8F1256D61ED5325EBF2A4B4366BA00000000000000000), viene restituito _hash.mod(q)_. In caso contrario, l'algoritmo 3 si ripete finché non raggiunge un hash numerico all'interno dell'intervallo valido. Per riferimento, si noti che _q_ è l'ordine primo del gruppo _G_, gli output hash Blake2b256 sono lunghi 256 bit e 64 cifre e l'algoritmo 3 restituirà sempre un hash numerico in _Z/qZ_.
 
_Funzione hash basata su Blake2b256_
![Screenshot 2022-06-02 at 03.17.18.png](https://storage.googleapis.com/ergo-cms-media/Screenshot_2022_06_02_at_03_17_18_ce898813d8/Screenshot_2022_06_02_at_03_17_18_ce898813d8.png)
 
Nella riga 2, il focus è la creazione di _list R_. _Lista R_ contiene valori _r_ che sono hash numerici a 31 byte creati da numeri interi in [0, N). I valori _r_ sono generati da _takeright(31,H(j||h||M))_. Le variabili sono le seguenti:

- _j_, intero in [0, N)
- _h_, altezza del blocco
- _M_, 8kb di dati costanti - riempimento per rallentare il calcolo dell'hash
 
 La sezione _takeRight(31,H(…))_ significa che dato _H(…)_, un output Blake2b256 a 32 byte, i 31 byte a destra (cioè in little endian (mentre altri algoritmi hash sono bit endian)) sono restituito. In altre parole, viene eliminato il byte più significativo, il byte più a sinistra. Di conseguenza, ogni valore _r_ corrisponde ai 31 byte meno significativi derivati ​​dall'output _H(j||h||M))_ a 32 byte. Ad esempio, se _j_ = 1, _r1 = takeRight(31,H(1||h||M))_._List R_ è costituito da _N_ elementi e può essere generato per ogni blocco incrementando _j_ di 1 _N-1_ volte. Poiché _H(…)_ restituisce _hash.mod(q)_, possiamo affermare che _list R_ consiste di _r0, 1, 2, 3 … N-1_ e _list R ⊂ Z/qZ_. Come affermato nel whitepaper di Autolykos v2[3], "_N_ elementi derivano dall'altezza e dalle costanti del blocco, a differenza di Autolykos v1, quindi i minatori possono ricalcolare facilmente i candidati al blocco ora (solo gli indici dipendono da essi)." In altre parole, _j_ è sempre in [0,N), _N_ è determinato da _h_, _M_ è sempre costante e _h_ cambia ogni blocco, l'unica variabile di cui un minatore ha bisogno per calcolare _list R_ è _h_.
 
_Lista R_ è memorizzato nella RAM. In Autolykos, _N_ = 226 (67.108.864 interi) viene utilizzato nell'implementazione per ogni blocco prima di 614400. Pertanto, il requisito di memoria per i blocchi prima del blocco 614400 è (226 * 31 byte =) 2,08 GB. N è aumentato per la prima volta nel blocco 614400. Post blocco 614400, ogni 51200 blocchi, _N_ aumenta del 5%. In altre parole, il fabbisogno di memoria di un minatore Ergo aumenta del 5% ogni ~71 giorni. Sul blocco 4198400 il valore di _N_ diventa costante e uguale a 2.143.944.600[4]. Si noti che gli ultimi 2 valori elencati nella tabella devono essere 2.143.944.600 e non 2.147.387.550. Dopo il blocco 4198400, il requisito di archiviazione di _list R_ sarà (31 byte * 2.143.944.600) = 66,46 GB.

_N elementi basati sull'altezza del blocco_
![senza nome (3).png](https://storage.googleapis.com/ergo-cms-media/unnamed_3_978ffb3d8a/unnamed_3_978ffb3d8a.png)
_N elementi, Ethash vs. Autolykos_
 
Autolykos è come Ethash nel senso che l'altezza del blocco determina _N_ elementi da memorizzare nella RAM. Con Autolykos, l'altezza del blocco determina _N_ hash numerici a 31 byte da memorizzare. Con Ethash, l'altezza del blocco determina _N_ 128B pagine DAG da memorizzare. Potresti chiederti, se si verifica un blocco Ergo ogni 2 minuti, in che modo i minatori Ergo sono in grado di generare un set di dati di oltre 2 GB così rapidamente? I minatori di Ethereum rigenerano il DAG solo ogni 100 ore perché ci vuole così tanto tempo... Per un minatore Ergo, l'onere per calcolare _list R_ è _N_ istanze dell'algoritmo 3; ricorda, ogni _r valore_ è calcolato come _takeRight(31,H(j||h||M))_. Tuttavia, una GPU può farlo molto rapidamente. Le GPU generalmente hanno multiprocessori da 32 o 64 larghezze, il che significa che è possibile eseguire 32 o 64 istanze dell'algoritmo 3 contemporaneamente a seconda della GPU. Ad esempio, una GPU da 32 pollici come l'RTX570 può riempire l'_elenco R_ in pochi secondi.

**Per la Parte II**, riprenderemo da qui e continueremo la spiegazione di Autolykos v2. Resta sintonizzato sui canali dei social media di Ergo per gli aggiornamenti sulla Parte II di questa serie.


[1] https://www.researchgate.net/publication/316904748_Equihash_Asymmetric_Proof-of-Work_Based_on_the_Generalized_Birthday_Problem
[2] https://en.wikipedia.org/wiki/Cyclic_group#/media/File:Cyclic_group.svg
[3] https://www.docdroid.net/mcoitvK/ergopow-pdf
[4] https://www.ergoforum.org/t/autolykos-v-2-details/480
[5] Ringraziamo Wolf9466#9466 su Discord