Spcnet.it

2026-05-27 12:38:29

Runtime Async in .NET 11 Preview 1: addio alle state machine del compilatore

Introduzione

Con il rilascio di .NET 11 Preview 1, Microsoft ha introdotto uno dei cambiamenti architetturali più significativi nella storia dell’async in .NET: il Runtime Async V2. Questo cambiamento sposta la responsabilità della gestione delle operazioni asincrone dal compilatore al runtime stesso, con impatti concreti su debug, profiling, leggibilità degli stack trace e potenzialmente sulle prestazioni.

In questo articolo analizziamo nel dettaglio come funziona il nuovo modello, come differisce dall’approccio attuale basato su state machine, come abilitarlo nei propri progetti e cosa aggiunge .NET 11 Preview 1 oltre al solo Runtime Async.

Il problema: le state machine del compilatore

Chiunque abbia lavorato seriamente con codice asincrono in C# conosce la frustrazione di leggere uno stack trace in produzione e trovarsi sommerso da frame generati dal compilatore. Ogni metodo async viene trasformato dal compilatore in una classe di stato (state machine) che implementa IAsyncStateMachine. Questa trasformazione è efficace, ma introduce livelli di indirezione che offuscano la reale catena di chiamate.

Un semplice stack di tre metodi async produce tipicamente oltre dieci frame nello stack trace live, la maggior parte appartenenti all’infrastruttura del compilatore (AsyncMethodBuilderCore.Start, ecc.). Il risultato è un debug più laborioso e strumenti di profiling che faticano a restituire una visione chiara dell’esecuzione.

Runtime Async V2: come funziona

Con Runtime Async, il compilatore non genera più la state machine. Emette invece un IL semplificato, annotato con [MethodImpl(MethodImplOptions.Async)], e delega al runtime la gestione della sospensione e ripresa dei metodi asincroni. In pratica, è il CLR stesso a tracciare l’esecuzione asincrona, non il codice generato dal compilatore.

Il risultato più visibile è nei live stack trace, ovvero ciò che profiler, debugger e new StackTrace() vedono durante l’esecuzione. Con Runtime Async, i metodi effettivi appaiono direttamente nello stack, senza wrapper di stato.

Confronto diretto degli stack trace

Consideriamo questo codice di esempio:

await OuterAsync();

static async Task OuterAsync()
{
    await Task.CompletedTask;
    await MiddleAsync();
}

static async Task MiddleAsync()
{
    await Task.CompletedTask;
    await InnerAsync();
}

static async Task InnerAsync()
{
    await Task.CompletedTask;
    Console.WriteLine(new StackTrace(fNeedFileInfo: true));
}

Senza Runtime Async — 13 frame, con tutta l’infrastruttura del compilatore visibile:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__InnerAsync|0_2()
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__MiddleAsync|0_1()
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
...
(13 frame totali)

Con Runtime Async — 5 frame, la reale catena di chiamate:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
at Program.<Main>$(String[] args) in Program.cs:line 3
at Program.<Main>(String[] args)

È importante notare che questo miglioramento riguarda i live stack trace. Gli exception stack trace (catch (Exception ex)) già apparivano in modo pulito grazie all’ExceptionDispatchInfo nelle versioni precedenti.

Miglioramenti al debugging

Con Runtime Async, il debugger può finalmente fare ciò che ci si aspetterebbe da sempre:

• I breakpoint all’interno di metodi async si associano correttamente, senza essere deviati su codice generato
• È possibile fare step-through attraverso i boundary degli await senza “saltare” nell’infrastruttura del compilatore
• La finestra call stack del debugger mostra la catena reale, non i wrapper di stato

Questi miglioramenti avvantaggiano qualsiasi strumento che ispeziona lo stack live: profiler come dotTrace, logging diagnostico, e naturalmente il debugger integrato di Visual Studio e VS Code.

Come abilitare Runtime Async nel proprio progetto

Runtime Async è una feature in anteprima che richiede opt-in esplicito. Aggiungere le seguenti proprietà al file .csproj:

<PropertyGroup>
  <Features>runtime-async=on</Features>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>

Ovviamente, essendo ancora in anteprima, non è consigliato per ambienti di produzione. È tuttavia un ottimo momento per sperimentarlo su branch di sviluppo e fornire feedback al team .NET.

Requisiti hardware aggiornati

.NET 11 alza il baseline hardware richiesto. Per x86/x64, il minimo passa da x86-64-v1 a x86-64-v2, richiedendo istruzioni aggiuntive come SSE3, SSSE3, SSE4.1, SSE4.2 e POPCNT. Questo rientra nei requisiti già imposti da Windows 11 e copre tutta l’hardware Intel/AMD attualmente supportato ufficialmente (i chip più vecchi sono usciti dal supporto intorno al 2013).

Per Arm64 su Windows, il baseline aggiunge ora il requisito dell’instruction set LSE, richiesto da Windows 11 e da tutti gli Arm64 supportati da Windows 10.

Altre novità di .NET 11 Preview 1

Supporto nativo a Zstandard

Le librerie guadagnano il supporto nativo alla compressione Zstandard tramite la nuova classe ZstandardStream. Zstandard offre rapporti di compressione migliori rispetto a gzip con velocità di decompressione molto elevate — un’aggiunta benvenuta per pipeline di dati e API ad alta frequenza.

BFloat16 per AI e ML

Arriva il tipo BFloat16 (Brain Float 16), un formato floating-point a 16 bit nato per carichi di lavoro di machine learning. È ampiamente usato da librerie AI come TensorFlow e PyTorch, e la sua presenza nativa in .NET facilita l’integrazione con modelli ML senza conversioni intermedie.

Miglioramenti JIT

• Eliminazione dei bounds check: il JIT elimina ora i controlli ridondanti sul pattern i + cns < len, comune nei loop su array e Span
• Rimozione di contesti checked ridondanti: quando un valore è già noto essere nel range, i controlli di overflow vengono rimossi
• Devirtualizzazione in ReadyToRun: le immagini R2R possono ora devirtualizzare chiamate a virtual method generici non condivisi

Miglioramenti VM

Su piattaforme senza JIT (come iOS), l’interface dispatch ora usa un meccanismo di cache con miglioramenti di performance fino a 200x in codice ad alta intensità di interfacce. Guid.NewGuid() su Linux migliora del 12% circa usando la syscall getrandom() con batch caching.

C# 15: prime anticipazioni

.NET 11 Preview 1 include anche le prime feature di C# 15. Tra quelle già disponibili:

• Collection expression arguments: possibilità di specificare capacità, comparatori o altri parametri del costruttore direttamente nella sintassi delle espressioni di collezione
• Extended layout support: il compilatore emette TypeAttributes.ExtendedLayout per tipi annotati con ExtendedLayoutAttribute, principalmente per scenari di interop

Conclusione

Il Runtime Async V2 rappresenta un passo importante verso un’esperienza di sviluppo asincrono più trasparente e debuggabile in .NET. Non è ancora pronto per la produzione, ma la direzione è chiara: Microsoft vuole che gli sviluppatori smettano di combattere con stack trace incomprensibili e possano finalmente fare debug dell’async come del codice sincrono.

Con .NET 11 previsto per novembre 2026 come Standard Term Support (STS), c’è ancora tempo per sperimentare e contribuire al processo di feedback prima del rilascio finale.

Fonte: What’s new in the .NET 11 runtime — Microsoft Learn | InfoQ: .NET 11 Preview 1

.NET 11 Preview 1 Arrives with Runtime Async, Zstandard Support, and C# 15 Features

NET 11 Preview 1 is released, featuring Runtime Async as the headline change, moving async method handling from the compiler into the runtime itself.

^{Almir Vuk (InfoQ)}

Spcnet.it

2026-05-27 12:36:33

GPUStack: cluster GPU self-hosted per inferenza AI con API OpenAI-compatibile

Avete le GPU. Magari un paio di NVIDIA A100 in un rack, alcune RTX 4090 sotto le scrivanie, o un cluster con hardware misto. Avete la potenza di calcolo. Bene. Adesso, però, viene il problema vero: come gestirla?

Capire quali modelli entrano in quale scheda, come bilanciare il carico tra più macchine, come gestire un nodo che cade alle 2 di notte, e come esporre tutto questo come una API pulita che il team di sviluppo possa effettivamente chiamare — questa è la parte che manda in crisi la maggior parte dei team. Il risultato tipico è una raccolta fragile di script Python e crontab entries che nessuno tocca da anni e che funzionano finché non smettono di funzionare.

GPUStack è stato costruito precisamente per risolvere questo problema.

Cos’è GPUStack?

GPUStack è uno strumento open source (licenza Apache 2.0) per la gestione di cluster GPU destinati all’inferenza AI. Pensatelo come Kubernetes per i vostri workload di inferenza, senza la necessità di passare tre giorni a debuggare un errore di indentazione in un Helm chart.

Al suo nucleo, GPUStack fa tre cose bene:

• Aggrega le GPU: che l’hardware sia su bare-metal, pod Kubernetes o istanze cloud, GPUStack le vede tutte come un unico pool di compute. Una dashboard, visibilità completa.
• Orchestrare gli inference engine: GPUStack si integra con vLLM, SGLang e TensorRT-LLM, sceglie il motore giusto per il job, lo configura e ne gestisce il ciclo di vita.
• Espone i modelli via API OpenAI-compatibile: una volta deployato un modello, il team applicativo ottiene un endpoint REST familiare. Nessuna libreria client custom. Nessun protocollo nuovo da imparare. Solo cambiare il base URL.

Installazione in meno di 5 minuti

Step 1 — Avviare il server di controllo

Vi serve una macchina per il control plane. Non deve nemmeno avere una GPU — un box CPU-only è sufficiente per il ruolo di server:

sudo docker run -d --name gpustack   --restart unless-stopped   -p 80:80   --volume gpustack-data:/var/lib/gpustack   gpustack/gpustack

Aprite il browser, navigate a http://<ip-del-vostro-server> e vedrete la dashboard GPUStack. Al primo accesso impostate le credenziali admin.

Step 2 — Aggiungere i worker GPU

Su ogni nodo worker, assicuratevi di avere installato NVIDIA driver e NVIDIA Container Toolkit, poi eseguite:

sudo docker run -d --name gpustack-worker   --restart unless-stopped   --gpus all   -e GPUSTACK_SERVER_URL=http://<ip-server>   -e GPUSTACK_TOKEN=<vostro-token>   gpustack/gpustack

Il token lo trovate nella dashboard GPUStack. In pochi secondi il worker compare nella vista cluster con modello GPU, capacità VRAM e stato di salute. Tre macchine? Tre comandi. Trenta macchine? Un playbook Ansible.

Nota pratica: la parte più difficile non è eseguire il comando worker, ma installare correttamente driver e toolkit sull’host. Verificate sempre la compatibilità tra versione del driver NVIDIA, versione CUDA e container runtime prima di procedere.

Step 3 — Deploy di un modello

Dalla web UI andate al catalogo modelli. GPUStack supporta il pull da Hugging Face e dall’Ollama Library. Selezionate un modello e cliccate “Deploy”.

Qui il scheduler dimostra il suo valore: legge i metadati del modello, calcola i requisiti di VRAM e compute, e determina quali worker possono gestirlo. Se il modello è troppo grande per una singola GPU, può distribuirlo su più schede (model sharding). Non dovete calcolare manualmente se un modello a 70B parametri entra nel vostro hardware: ci pensa GPUStack.

Step 4 — Chiamare l’API

Una volta che il modello è running, ottenete un endpoint OpenAI-compatibile. Recuperate una API key dalla dashboard e testate:

curl http://<ip-server>/v1/chat/completions   -H "Authorization: Bearer <api-key>"   -H "Content-Type: application/json"   -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Spiega la gestione di cluster GPU in un paragrafo."}
    ]
  }'

Se usate già l’OpenAI Python SDK, la migrazione alla vostra infrastruttura è una modifica su una riga:

from openai import OpenAI

client = OpenAI(
    base_url="http://<ip-server>/v1",
    api_key="<api-key>"
)

response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Hello from my own GPU cluster!"}]
)
print(response.choices[0].message.content)

Il codice applicativo rimane invariato. La vostra infrastruttura è ora completamente sotto il vostro controllo.

Funzionalità Avanzate

Flessibilità Multi-Backend

GPUStack supporta vLLM, SGLang e TensorRT-LLM out of the box. Nessun motore di inferenza è il migliore per ogni workload:

• vLLM: eccellente per batch processing ad alto throughput
• TensorRT-LLM: massimizza le performance sull’hardware NVIDIA
• SGLang: ideale per la generazione strutturata

GPUStack vi permette di scegliere il motore giusto per ogni deployment, o di lasciare che il scheduler scelga per voi in base al workload.

Monitoraggio Integrato

GPUStack si integra nativamente con Grafana e Prometheus, offrendo dashboard in real-time per utilizzo GPU, consumo VRAM, token throughput e request rate dell’API. Non serve aggiungere uno stack di monitoraggio separato. Quando qualcosa si rompe alle 2 di notte, saprete esattamente quale GPU su quale macchina è il problema.

Recovery automatico dai guasti

Un nodo che cade a causa di un errore PCIe bus o un driver mismatch che si manifesta solo sotto carico pesante tipicamente porta la vostra API di inferenza a restituire 500 finché non intervenite manualmente. GPUStack rileva i nodi non raggiungibili e redistribuisce i workload automaticamente, eliminando la necessità di un intervento manuale d’emergenza.

Quando Usare GPUStack

GPUStack è la scelta giusta se:

• Avete 2 o più macchine GPU e volete servire LLM o altri modelli AI tramite una API unificata
• Volete eseguire inferenza sulla vostra hardware invece di pagare per token a un cloud provider — il risparmio sui costi a scala è reale
• Il vostro team non vuole diventare ingegneri di infrastruttura a tempo pieno solo per tenere i modelli in funzione

Forse non è la scelta giusta se:

• Avete una singola GPU e volete solo eseguire modelli localmente per uso personale: in quel caso Ollama è più semplice
• Siete già profondamente integrati in una piattaforma ML custom su Kubernetes con KubeFlow o simili, dove l’overlap potrebbe non valere l’investimento

Il Quadro Generale: l’Inferenza Self-Hosted è di Nuovo Praticabile

Il panorama dell’infrastruttura AI sta cambiando rapidamente. Un anno fa la maggior parte dei team optava automaticamente per API provider per l’inferenza. Oggi, con modelli open-weight sempre più capaci e costi GPU in calo, l’inferenza self-hosted è diventata un’opzione reale — non solo per i grandi player, ma per startup e aziende di medie dimensioni.

Il collo di bottiglia non è più l’hardware. Sono le operations: il codice collante tra “abbiamo le GPU” e “la nostra applicazione può chiamare un modello in modo affidabile”. GPUStack è un tentativo serio di risolvere questo gap, ed è open source sotto licenza Apache 2.0 — ispezionabile, modificabile e deployabile senza vendor lock-in.

Se avete hardware che al momento scalda solo la stanza server, o se siete stanchi di bollette di inferenza cloud che sembrano mutui, vale la pena provare. Il progetto è disponibile su GitHub.

Fonte originale: Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack — DZone

Learn How to Use GPUStack

Struggling to manage GPU clusters? Discover how GPUStack simplifies self-hosted AI inference with an easy-to-use, open-source, OpenAI-compatible API.

^{Sandeep Sadarangani (dzone.com)}

(in)sicurezza digitale

2026-05-27 07:47:40

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON

Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded

KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE

L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma

Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali

L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi

• Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
• 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
• 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426

Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori

La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.

Destinazione Stelle

2026-05-25 07:26:42

Quiz del lunedì. A che temperatura operava lo strumento HFI del satellite europeo Planck?

Appuntamento a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia

Destinazione Stelle

2026-05-26 07:08:25

Planck è stato un satellite europeo, operativo tra il 2009 e il 2013, con l’obiettivo di misurare la radiazione cosmica di fondo e migliorare la nostra conoscenza sulle origini e l’evoluzione dell’universo. Era equipaggiato con due sofisticati strumenti: il Low Frequency Instrument (LFI) e l'High Frequency Instrument (HFI). Oltre a partecipare alla costruzione del satellite, l'Italia è stata responsabile dell’LFI, con il ruolo di Principal Investigator affidato a Nazzareno Mandolesi dell’INAF-IASF di Bologna, ma ha partecipato anche alla realizzazione dell'HFI. Per entrambi gli strumenti, gli scienziati italiani sono stati fortemente coinvolti nell’attività scientifica legata alla missione, che ha realizzato la più accurata e dettagliata mappatura dell'intera volta celeste alle frequenze delle microonde mai ottenuta fino a quel momento.

Per misurare le infinitesimali variazioni di temperatura della radiazione cosmica di fondo, pari a pochi milionesimi di grado, i due strumenti dovevano essere mantenuti a temperature eccezionalmente basse. Questo obiettivo è stato raggiunto con una complessa catena di raffreddamento a stadi successivi. I due strumenti lavoravano a temperature diverse ed erano inseriti uno dentro l'altro.

Per prima cosa era necessario isolare gli strumenti dalla parte “calda” del satellite, il modulo di servizio orientato verso il sole. Questo obiettivo è stato ottenuto con un sistema di scudi termici molto ingegnoso ed eccezionalmente efficiente chiamato “V-grooves”: lo stesso principio poi adottato dal telescopio James Webb. In questo modo si è riusciti a portare la temperatura del payload a 50 Kelvin, circa -223 °C, una temperatura già molto bassa ma non ancora sufficiente.

Lo strumento LFI veniva poi portato a circa 20 Kelvin (-253 °C) con un particolare refrigeratore a idrogeno che aveva la caratteristica di non usare alcuna parte meccanica in movimento, eliminando così qualsiasi vibrazione che potesse disturbare le misurazioni scientifiche.

Lo strumento HFI veniva invece raffreddato con tre stadi successivi, l’ultimo dei quali sfruttava il principio della “diluzione d’elio”: questo stadio faceva miscelare continuamente due isotopi rari dell'elio, l'elio-3 e l'elio-4, con un processo endotermico, capace di assorbire calore, un po’ come l'evaporazione di un liquido, e di sottrarre le ultime frazioni di microwatt, per arrivare a una temperatura di un decimo di Kelvin (-273,05 °C). La temperatura "naturale" della radiazione cosmica di fondo è di circa 2,7 K (-270,45 °C), quindi lo strumento HFI era molto più freddo dell’ambiente circostante: un risultato possibile soltanto grazie a sistemi di raffreddamento attivi.

All’epoca lo strumento HFI era l’oggetto più freddo noto nello spazio, nonché il più freddo oggetto artificiale, ma in seguito questo record è stato superato. Attualmente l’esperimento della NASA Cold Atom Lab (CAL), a bordo della Stazione Spaziale Internazionale, è in grado di arrivare a temperature dell'ordine di poche decine di picokelvin, cioè meno di un decimiliardesimo di Kelvin.

@astronomia

♲ @destinazione_stelle@poliversity.it:

Quiz del lunedì. A che temperatura operava lo strumento HFI del satellite europeo Planck?
Appuntamento a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia