If you made something blink, and now it’s time for you to make something move, something like a point-to-a-satellite tracker is a great idea. [Farid] made this moving arrow that always points at the ISS, and documented it nicely to boot.

And there’s a little bit of everything here, from orbital mechanics and fetching the two-line elements (TLE) from the web, to writing the code to translate that into the tabletop machine’s coordinate system. It looks like [Farid] hadn’t done much 3D CAD before, so he got a chance to stretch those muscles too. Finally, it served as an introduction to resource-constrained programming: “This was the first time I’ve had to think about the size of a compiled binary – the most frustrating part was figuring out that using a C++ stringstream was adding too much code to my binary.”

[Farid] is learning a lot here, and you might too. For instance, using pencil lead (graphite) as a lubricant on sliding 3D-printed parts is new to us, but makes sense. We’ll have to try that out.

And while this is a simple desktop tracker, with a lot more mechanical design, the same basics could be put to real use for pointing a receiver dish. Of course, who says you need fancy motors and computers to point a satellite dish anyway? If you work on your arm muscles a bit, you could become the satellite pointer.

hackaday.com/2025/04/07/tracki…

Gli esperti di SafeBreach hanno segnalato che le patch rilasciate da Google l’anno scorso per correggere le vulnerabilità di Quick Share che potevano portare all’esecuzione di codice in remoto erano incomplete e potevano essere facilmente aggirate.

Quick Share (in precedenza Nearby Share) è un’utilità di condivisione file P2P sviluppata originariamente solo per Android, ma successivamente rilasciata per Windows e Chrome. Consente di inviare file a dispositivi compatibili nelle vicinanze, supportando Bluetooth, Wi-Fi, Wi-Fi Direct, WebRTC e NFC.

Lo scorso agosto, i ricercatori di SafeBreach hanno pubblicato i dettagli di 10 vulnerabilità in Quick Share per Windows che consentivano agli aggressori di scrivere file su un dispositivo di destinazione senza l’autorizzazione dell’utente, causare arresti anomali, reindirizzare il traffico ed eseguire altre azioni dannose.

All’epoca, agli errori rilevati venivano assegnati due identificatori: CVE-2024-38271 (5,9 punti sulla scala CVSS) e CVE-2024-38272 (7,1 punti sulla scala CVSS). Gli sviluppatori di Google hanno risolto rapidamente i problemi poiché potevano essere utilizzati in attacchi man-in-the-middle (MiTM) e portare all’esecuzione di codice remoto (RCE).

Come avvertono ora gli esperti di SafeBreach, le patch dell’anno scorso erano incomplete e Quick Share è rimasto vulnerabile ad attacchi di tipo Denial of Service (DoS) e alla scrittura remota di file arbitrari.

Pertanto, secondo gli esperti, Quick Share potrebbe bloccarsi quando si invia un file il cui nome contiene byte di continuazione UTF-8 non validi. Inizialmente si pensava che l’attacco potesse utilizzare solo il terminatore nullo, ma ulteriori indagini dopo il rilascio della patch hanno dimostrato che potevano essere utilizzati anche altri byte di continuazione non validi.

Inoltre, gli esperti hanno scoperto che una patch per il problema della scrittura non autorizzata di file, che causava l’eliminazione di un file sconosciuto da parte di Quick Share, non risolveva il problema.

“Questa vulnerabilità critica ha consentito a un aggressore di eludere la necessità di ottenere il consenso per trasferire un file da un utente Quick Share e invece inviare il file direttamente al suo dispositivo senza approvazione”, spiega SafeBreach.

Google ha risolto il problema forzando Quick Share a contrassegnare tali file come “sconosciuti” e ad eliminarli. Ma gli sviluppatori non hanno preso in considerazione la possibilità di trasferire due file con lo stesso ID payload all’interno della stessa sessione. Per questo motivo l’applicazione ha eliminato solo il primo file inviato.

“Siamo stati in grado di lanciare esattamente lo stesso exploit della vulnerabilità originale, ma ora abbiamo inviato due pacchetti PayloadTransfer di tipo FILE. Abbiamo specificato nomi di file e contenuti diversi per i due pacchetti, ma impostato gli stessi ID di payload”, hanno affermato gli esperti.

Al bypass della patch è stato assegnato l’identificatore CVE-2024-10668 e gli sviluppatori di Google hanno nuovamente corretto la vulnerabilità a novembre 2024. Quick Share per Windows versione 1.0.2002.2 contiene ora le patch per tutte le vulnerabilità rilevate da SafeBreach.

“Sebbene il nostro studio si sia concentrato sull’utilità Quick Share, riteniamo che i nostri risultati siano applicabili all’intero settore del software e suggeriscano che, anche quando il codice è complesso, i fornitori dovrebbero sempre affrontare la vera causa principale delle vulnerabilità”, concludono i ricercatori.

L'articolo Google rilascia patch per Quick Share… ma era solo una toppa bucata proviene da il blog della sicurezza informatica.

A novembre dell’anno scorso, la direzione di Hunters International aveva annunciato al suo team che il progetto sarebbe stato chiuso, affermando che il “rebranding” in World Leaks era già in pieno svolgimento.

Il gruppo World Leaks ha lanciato il sito nelle darknet il 1° gennaio di quest’anno concentrandosi esclusivamente sul furto di informazioni, annunciando di non avere più l’intenzione di utilizzare il ransomware. Le tattiche infatti si sarebbero basate sul furto di dati e sull’estrazione del massimo beneficio da essi, estorcendo riscatti alle aziende vittime o vendendo le informazioni a chi è interessato.

Questo perché il ransomware non è più redditizio e le forze dell’ordine e gli investigatori internazionali prestano troppa attenzione agli hacker da profitto e quindi non ne vale più la pena. Nel loro annuncio di novembre, Hunters International ha scritto:
Nonostante i grandi sforzi investiti nella creazione e nello sviluppo congiunto del progetto, io e la maggior parte dei partner abbiamo deciso che lo sviluppo nella direzione del Ransomware era diventato poco promettente, poco conveniente ed eccessivamente rischioso.

Nel mondo stanno avvenendo dei cambiamenti, uno dei quali è il riconoscimento del Ransomware come terrorismo e dei paesi che contribuiscono (o non fanno nulla) a tale fenomeno, come paesi che sostengono i terroristi.

Questo status è inaccettabile per la maggior parte dei Paesi, poiché ha un impatto negativo sul sistema bancario estero. Ciò significa che la lotta contro il ransomware si sta spostando dal piano virtuale a quello reale, e questa volta i nostri stessi Stati sono contro di noi. In una situazione del genere, le possibilità di sopravvivenza tendono a zero.

Il ransomware è un argomento molto interessante, ormai ampiamente studiato. Continuare a lavorare in questo settore significa mettere a rischio la propria vita e quella dei propri cari. Ricordatevi, non siamo terroristi.

Grazie alle nostre competenze specialistiche, possiamo ottenere molto di più, ottenere il tasso di conversione desiderato e pagamenti multimilionari. Insieme possiamo fare qualsiasi cosa! "Arrivederci!"
Tuttavia, poche settimane dopo la pubblicazione di questo messaggio, Hunters International è tornato ad essere attivo ipotizzano che potrebbe esserci stata una divisione nel gruppo o una sorta di confusione deliberata o accidentale.

In ogni caso, il rebranding in World Leaks è ancora possibile e, nonostante alcuni problemi con il sito (errori che hanno costretto gli amministratori a chiudere il sito subito dopo il lancio), il progetto è vivo, anche se gli hacker non hanno ancora rivendicato la responsabilità di alcun attacco.

World Leaks offre ai propri membri l’accesso a un software di furto dei dati facile da usare e difficile da rilevare, che si collega tramite proxy a un pannello di controllo online per i partner del gruppo. Se Hunters International abbandonasse davvero l’uso del ransomware, il gruppo si unirebbe ai suoi numerosi “colleghi” che hanno già adottato misure simili. Gli esperti di sicurezza informatica hanno da tempo notato una tendenza all’aumento del numero di criminali che abbandonano il ransomware e preferiscono l’estorsione pura.

Ad esempio, nel 2022, il gruppo estorsivo Karakurt ha smesso di crittografare i dati delle sue vittime e, un anno dopo, il gruppo di hacker BianLian ha fatto lo stesso. Da allora sono comparsi sulla scena nuovi hacker che fin dall’inizio si dedicavano esclusivamente all’estorsione. Un esempio è il gruppo Mad Liberator nato circa un anno fa.

Tuttavia, non si può dire che il ransomware non porti più profitti ai suoi operatori. Ad esempio, il rapporto Sophos del 2024 ha rilevato che il numero di riscatti pagati ai criminali informatici per il recupero dei dati è aumentato di 2,6-5 volte rispetto all’anno precedente.

L'articolo I Criminali Hanno Paura del Ransomware! Molti Lasciano L’Arena Per Dedicarsi al Furto dei Dati proviene da il blog della sicurezza informatica.

Tradizionalmente, l’AI inference è stato il dominio di data center centralizzati e cluster di calcolo ad alte prestazioni, accessibili solo a pochi. Questo è ancora il caso per molte decentralized inference networks, dove gli operatori dei nodi devono affidarsi a hardware di fascia alta per poter guadagnare ricompense che, di fatto, servono solo a mitigare le loro spese.

Questo non democratizza l’accesso all’AI: la maggior parte degli utenti non è in grado di partecipare attivamente alla fase di inference a causa degli elevati costi delle GPU, e i clienti che desiderano un decente livello di decentralizzazione o privacy si ritrovano con soluzioni davvero lente o costose.

Negli ultimi mesi, il team di BrianknowsAI ha lavorato su qualcosa che potrà essere una svolta nell’intersezione tra AI e web3: il DCI Network. Ma prima di parlarne, facciamo un passo indietro e vediamo perché ci siamo trovati in questa situazione in primo luogo.

Background

Le Neural Networks sono, come suggerisce il nome, reti di neuroni artificiali organizzati in strati. Tutti i neuroni in uno strato eseguono la stessa operazione sui dati di input forniti, spesso definiti come operators. Gli strati all’interno di una Neural Network sono connessi tramite bordi pesati; regolare questi pesi durante il training è ciò che fa “imparare” una Neural Network. Questi pesi sono spesso chiamati parameters.

Oggi le Neural Networks crescono costantemente in complessità, e quando la loro complessità aumenta, crescono anche i requisiti computazionali e l’memory footprint per eseguire sia l’inference che il training.

Modelli complessi hanno più strati, più neuroni e architetture più grandi, il che contribuisce a un enorme numero di operazioni matematiche che devono essere calcolate. Quando un dispositivo esegue questi calcoli, deve memorizzare il risultato in memoria.

Una Neural Network è “grande” quando si verifica una (o più) delle seguenti condizioni:

• Ha molti operators -> richiede più potenza computazionale
• Ha molti parameters -> richiede più memoria per memorizzare i pesi
  (Ignoro il caso del training, dove dovremmo considerare anche la dimensione dei dati di esempio per il training).

Durante la fase di inference di una Deep Neural Network (DNN), i dati di input vengono elaborati attraverso ogni strato della rete per produrre un output. Due fattori critici influenzano questa fase: l’memory footprint (la quantità di memoria necessaria per contenere la rete e i dati) e i GOP (Giga [10⁹] Operations) richiesti per generare il risultato. Se un dispositivo non ha memoria sufficiente per ospitare l’intera rete, non può eseguire l’inference. Anche se la memoria è adeguata, una potenza di calcolo limitata può causare ritardi significativi nell’elaborazione, rendendo l’inference impraticabilmente lenta su dispositivi meno potenti.

Il problema che vogliamo risolvere è: “Come possiamo eseguire l’inference di un modello grande su un dispositivo limitato dall’hardware?”. O, in altre parole, come possiamo usare un modello grande su un dispositivo che non è in grado di gestire gli operators e i parameters del modello?

Immaginiamo il concetto “astratto” di DNN come il concetto di Graph, dove i dati sono rappresentati da tensors e calcolati da operators. Un tensor è un vettore n-dimensionale di dati (o tensore) che scorre attraverso il graph (o NN); ci sono due tipi di tensors: input tensors (X) e output tensors (Y). Un esempio di input tensors sono i parameter tensors (che servono come input statico per gli operators). Quando un tensor è il risultato dell’output di un operator, viene chiamato activation tensor.

Eseguire l’inference su un modello significa calcolare tutte le attivazioni degli operators usando un input tensor (il nostro prompt nel caso di un LLM) e ottenere l’output tensor (il nostro risultato — un’immagine, un testo, ecc.).

Sfide attuali e soluzioni

La tendenza attuale nello sviluppo dei large language models (LLMs) si concentra sullo scaling up, ossia sull’espansione delle dimensioni dei modelli e sul miglioramento delle capacità hardware. Sebbene questo approccio ottenga prestazioni all’avanguardia, introduce sfide significative quando si tratta di distribuire o interagire con tali modelli:

• Costi elevati e complessità — Gli LLMs sono molto intensivi in termini di risorse, richiedendo hardware potente per essere efficienti o anche solo per funzionare. Ciò significa che la loro distribuzione in ambienti o dispositivi locali è proibitivamente costosa.
• Problemi di latenza — Il nostro mondo attuale si basa su applicazioni sensibili al tempo, e trasmettere dati avanti e indietro tra server basati su cloud introduce una latenza significativa, portando a prestazioni non ottimali o persino rischi per la sicurezza in casi d’uso critici.
• Preoccupazioni sulla privacy — Trasmettere dati sensibili su internet a server centralizzati comporta alti rischi per la privacy. Una volta che i dati lasciano il nostro dispositivo, non abbiamo controllo su come vengono usati o conservati: dati sensibili come quelli sanitari o personali potrebbero essere intercettati o utilizzati impropriamente durante la trasmissione.

Diverse strategie vengono sfruttate per mitigare queste sfide, specialmente per ridurre i requisiti computazionali degli LLMs. Queste tecniche funzionano semplificando i modelli senza degradarne gravemente le prestazioni:

• La Quantization riduce la precisione dei parameters del modello, abbassando l’memory footprint. Questo metodo ha i suoi limiti, poiché ridurre troppo la precisione può degradare l’accuratezza del modello, e non tutto l’hardware supporta operazioni con precisione inferiore.
• La Distillation comporta l’addestramento di un modello più piccolo (“studente”) per replicare le prestazioni di un modello più grande (“insegnante”), riducendo così la dimensione del modello.
• Il Pruning rimuove i parameters non necessari dai modelli, diminuendo il carico computazionale.

Per ulteriori informazioni su queste soluzioni, puoi consultare il mio articolo precedente:
Efficient Deep Learning: Unleashing the Power of Model Compression
Accelerare la velocità di inference del modello in produzione
towardsdatascience.com

Questi metodi possono aiutare ma non si adattano completamente ai modelli grandi, e in tutti i casi c’è un compromesso sulle prestazioni. Invece di affidarsi a un singolo dispositivo, prendiamo in considerazione la distribuzione del calcolo su più dispositivi. Formando una rete di dispositivi, ciascuno contribuendo al calcolo complessivo, i modelli più grandi possono essere eseguiti in modo più efficiente. Questo permette anche:

• Scalabilità — Aggiungere più dispositivi alla rete aumenta la memoria totale e la potenza di calcolo disponibili, rendendo possibile gestire modelli più grandi senza sovraccaricare i singoli dispositivi.
• Tolleranza ai guasti — Una rete decentralizzata ed eterogenea di dispositivi riduce il rischio di tempi di inattività. Se un dispositivo fallisce, gli altri possono continuare a elaborare, garantendo che il sistema rimanga operativo.
• Preservazione della privacy — In un sistema distribuito, i dati non vengono inviati a un singolo server centralizzato. Al contrario, le informazioni vengono condivise ed elaborate attraverso la rete, preservando la privacy. Poiché nessun singolo server ha accesso a tutti i dati degli utenti, il rischio che informazioni sensibili vengano utilizzate impropriamente è significativamente ridotto.

Cos’è il DCI Network?

Il Decentralized Collaborative Intelligence Network, o DCI Network, è una rete di nodi che condividono potenza computazionale per eseguire inference su modelli open source.

Per “collaborative intelligence” intendiamo un sistema distribuito in cui più attori contribuiscono a risolvere un problema specifico calcolando autonomamente una parte della soluzione di tale problema. Nel contesto del DCI Network, gli attori sono i nodi, il problema è l’inference di un modello e la soluzione è il risultato dell’inference.

Distributed Model Parallelism

L’approccio che vogliamo usare è dividere il neural network graph in subgraphs e assegnare ogni subgraph a un dispositivo specifico. Eseguendo l’inference su questi subgraphs, riduciamo drasticamente i requisiti computazionali su ogni dispositivo.

Il processo di divisione del graph in subgraphs è noto come Layer Sharding. Gli strati e/o sottostrati possono essere allocati ai dispositivi del DCI Network in diversi modi basati su una varietà di strategie.

Concetti chiave del Layer Sharding

• Model partitioning — Il modello è diviso in segmenti (i subgraphs), ciascuno composto da uno o più strati. Questi segmenti saranno distribuiti tra i dispositivi.
• Sequential execution — L’inference procede sequenzialmente attraverso i vari strati, e ogni risultato intermedio viene passato da dispositivo a dispositivo.

Quando si implementa il Layer Sharding in modo orizzontale (sequenziale), all’interno di una rete di dispositivi con diverse potenze computazionali, ci sono due sfide principali da affrontare (ne parleremo più avanti):

• Layer Assignment — Dobbiamo trovare il modo migliore per assegnare uno o più strati a ogni dispositivo. Ad esempio, gli strati che richiedono un maggiore consumo di memoria potrebbero essere distribuiti su più dispositivi con meno memoria disponibile.
• Effective Communication — I dispositivi della rete devono comunicare in modo efficiente e veloce. Inoltre, i messaggi non devono essere persi durante la comunicazione, altrimenti l’intero processo di inference collassa.

Sfide del DCI Network

Sviluppare una rete del genere pone molteplici sfide:

• Distribution Selection — Come può essere scelta una configurazione ottimizzata? Questo include determinare dove partizionare la rete e allocare i compiti tra i dispositivi. Lo spazio di ricerca per le possibili configurazioni potrebbe essere troppo grande per essere testato esaustivamente, richiedendo algoritmi per guidare la selezione. La sfida è come modellare questo problema di ottimizzazione.
• Devices — Quanti dispositivi sono disponibili, e sono identici o differiscono nelle caratteristiche? È disponibile una modellazione delle prestazioni (in termini di latenza ed energia), o è necessario il profiling per prendere decisioni informate?
• Metrics and Constraints — Quali sono le metriche primarie (es. velocità, energia) da ottimizzare? Se ci sono più metriche, ci sono priorità tra di esse? Ci sono vincoli rigidi da considerare?
• Adaptability — Il sistema dovrebbe adattarsi a cambiamenti dinamici (es. fluttuazioni di banda, cambiamenti nel numero di dispositivi) o dovrebbe essere configurato una sola volta al momento della compilazione, rimanendo statico successivamente?

In un sistema runtime statico, l’algoritmo di distribuzione viene eseguito solo una volta durante la fase di compilazione di un DNN. Dopo questo, la rete viene partizionata e assegnata a diversi dispositivi, che vengono poi utilizzati per le operazioni effettive. Poiché la distribuzione è determinata al momento della compilazione, si possono impiegare algoritmi più complessi per un’allocazione ottimale dei compiti, non essendo vincolati da prestazioni in tempo reale. Questo permette un’analisi approfondita e un’esecuzione algoritmica più lunga senza influire sulle prestazioni runtime del sistema.

In un sistema runtime adattivo, la topologia della rete cambia dinamicamente per ottimizzare alcune metriche. La variabile più comune monitorata è di solito la banda tra i dispositivi della rete. In questo modo, è possibile modificare le allocazioni dei dispositivi per ottimizzare latenza e bilanciamento del carico.

La ricerca relativa al calcolo distribuito si è concentrata principalmente sull’ottimizzazione di tre aspetti di tali reti:

• Latency — Tempo richiesto dal sistema per eseguire l’intero processo dall’ottenimento dei dati di input alla generazione del risultato di output;
• Throughput — Numero di input che il sistema può processare al secondo;
• Energy — Energia necessaria per comunicare ed elaborare un input.

La maggior parte degli studi si concentra sull’ottimizzazione di un solo tipo di metrica, e il nostro obiettivo primario è ottimizzare la metrica della latency. Tuttavia, crediamo che generare problemi di ottimizzazione multi-obiettivo si presenti come una direzione di ricerca e sviluppo promettente.

Vedremo nei prossimi paragrafi come intendiamo affrontare queste sfide.

Architettura

I nodi del DCI Network svolgono due scopi principali all’interno della rete:

• Inference — Calcolare l’inference del modello.
• Validation — Validare il risultato degli altri nodi per la generazione delle ricompense.

Il DCI Network è una rete P2P. La topologia della rete è costruita tramite un graph; ogni nodo del graph contiene il suo ID e la descrizione del dispositivo stesso (memoria, chip, ecc.). La scoperta dei peer avviene attraverso questo graph.

Un nodo, per entrare a far parte di questa rete, deve possedere la private key o la seed phrase di un wallet che ha messo in staking una quantità fissa di token.

Inference

Nel DCI Network, qualsiasi dispositivo può partecipare: che si tratti di un MacBook Pro, un laptop Linux o un dispositivo mobile (come un telefono iOS). Questo è possibile grazie al già citato distributed model parallelism.

Abbiamo già descritto come possiamo considerare una Neural Network come un graph e come il DCI Network sia strutturato esso stesso come un graph. Per semplificare la comprensione dei passaggi successivi:

• Con “model graph” ci riferiamo alla struttura a grafo di una Neural Network (o modello);
• Con “network graph” ci riferiamo alla struttura a grafo dei nodi connessi al DCI Network.

Abbiamo anche discusso come creare subgraphs del model graph iniziale ci permetta di distribuirli su più dispositivi per risolvere il problema legato ai requisiti hardware.

Il nostro obiettivo ora è trovare la migliore partitioning strategy per assegnare gli strati a ogni dispositivo nel modo più efficace.

Con partitioning strategy intendiamo un algoritmo che divide in modo ottimale gli strati del modello e li assegna a un nodo della rete per essere calcolati. Descriviamo la Ring Memory-Weighted Partitioning Strategy (proposta da Exo Labs) e poi proponiamo la nostra soluzione più avanzata.

In una rete a forma di anello, ogni nodo riceverà l’input per il suo chunk di modello locale dal nodo precedente nella catena di comunicazione, e lo elaborerà per trasmettere il suo output al nodo successivo. A causa della natura autoregressiva degli LLMs, le informazioni di output dovranno essere reinserite nell’input per generare un altro token. Ecco perché le strategie di partizionamento proposte sono le più adatte al nostro caso d’uso.

Ring Memory-Weighted Partitioning Strategy

In questa strategia, la rete funziona dividendo il flusso di lavoro usando un partizionamento pesato tra tutti i nodi che partecipano alla rete. Ogni dispositivo contribuisce all’inference in base alla seguente formula:

n = device_memory / total_memory

dove n è il numero di partizioni del modello, device_memory è la memoria disponibile del dispositivo per l’inference e total_memory è la quantità totale di memoria della rete. La memoria totale della rete viene calcolata tramite la trasmissione delle risorse disponibili dagli altri nodi.

In altre parole, ogni dispositivo contribuisce proporzionalmente a quante risorse condivide con la rete rispetto a quanto è grande la rete, ed è ricompensato in base a tale proporzione.

Usando una Ring Memory-Weighted Partitioning Strategy (come quella illustrata nell’immagine proposta da Exo Labs nella loro implementazione exo), i nodi sono ordinati per la loro memoria totale in ordine crescente, e in base al loro valore n (calcolato nella formula sopra) vengono determinati uno strato iniziale e uno finale del modello. Questi saranno gli strati iniziale e finale del modello che quel particolare nodo utilizzerà per l’inference.

Layer-Aware Ring Memory-Weighted Partitioning Strategy

Proponiamo un’evoluzione della Ring Memory-Weighted Partitioning Strategy: la chiamiamo Layer-Aware Ring Memory-Weighted Partitioning Strategy (o Layer-Aware RMW).

La Ring Memory-Weighted Partitioning Strategy è una strategia statica: ciò significa che il partizionamento prende in considerazione solo le risorse della rete e viene aggiornato solo quando un nodo si unisce o lascia la rete.

La nostra soluzione, invece, è dinamica perché cambia ogni volta in base al modello richiesto: questo perché il partizionamento non si basa solo sulle risorse della rete, ma calcoliamo anche le necessità computazionali di ogni strato del modello e assegniamo gli strati più intensivi dal punto di vista computazionale ai dispositivi con le migliori prestazioni nella rete.

Per far funzionare questo, dobbiamo eseguire:

• Device Profiling — Quando un dispositivo si unisce alla rete, recupera le sue capacità CPU/GPU e la capacità di memoria e le condivide con gli altri nodi.
• Model Profiling — I modelli open source utilizzabili nel DCI Network hanno ciascuno dei loro strati profilati, quindi sappiamo quali risorse sono necessarie per ottimizzare il calcolo su quello specifico strato.

Dato un insieme di strati (con le loro complessità computazionali e requisiti di memoria associati) e un insieme di dispositivi (la nostra rete) con le loro potenze di elaborazione, dobbiamo risolvere un problema di ottimizzazione in cui l’obiettivo è bilanciare il carico computazionale e l’uso della memoria tra tutti i dispositivi.

Risolvere questo problema significa:

• Minimizzare qualsiasi squilibrio computazionale tra i dispositivi.
• Garantire che i vincoli di memoria non vengano violati durante l’assegnazione degli strati ai dispositivi.
• Ottimizzare per una comunicazione inter-dispositivo minima.

Validazione

Essendo il DCI Network una rete decentralizzata, dobbiamo fornire validation (o verifica) per garantire che i nodi stiano effettivamente eseguendo l’inference sugli strati corretti e restituendo l’output corretto al nodo successivo/all’utente.

Abbiamo quindi introdotto il concetto di staking per permettere ai nodi di entrare nella rete.

Lo staking è una strategia usata nel mondo delle criptovalute e del web3 che consente agli utenti di partecipare a mantenere una rete blockchain onesta e sicura.

Ora dobbiamo vedere come e perché dovremmo eseguire lo slashing su tali stakeholder in caso agiscano in modo malevolo. Quando si parla di inference verificabile, ci sono due tipi di approcci che potremmo adottare: proof-based e cryptoeconomics-based.

Proof-based validations

Le proof-based validations, come suggerisce il nome, sono approcci che usano prove per verificare che l’inference sia stata eseguita correttamente. Per l’ambito del DCI Network, prenderemo in considerazione solo due tipi di proof-based validation: Zero-Knowledge Proofs e Optimistic Fraud Proofs. I seguenti tre paragrafi sono un estratto dell’eccellente lavoro svolto in questo paper.

Zero-Knowledge Proofs

zkML (Zero-Knowledge Machine Learning) rappresenta un nuovo paradigma all’intersezione tra ML e Blockchain: sfruttando zk-SNARKS (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), protegge la riservatezza nei parameters del modello e nei dati degli utenti sia durante il training che nei processi di inference. Questo può mitigare le preoccupazioni sulla privacy ma anche ridurre il carico computazionale sulla rete blockchain.

Ciò che è più affascinante di zkML è il fatto che è in grado di generare prove di dimensione fissa, indipendentemente da quanto grande sia il modello. Questo approccio crittografico, inoltre, garantisce sempre la correttezza.

D’altra parte, il costo di compilare un DNN in un circuito zero-knowledge si è dimostrato estremamente difficile e anche estremamente costoso: alcuni studi hanno mostrato un aumento di 1000 volte del costo dell’inference e della latenza (a causa della generazione della prova). Anche se questo costo può essere distribuito tra i nodi o trasferito all’utente, rimane comunque molto elevato.

Optimistic Fraud Proofs

opML (Optimistic Machine Learning) porta invece un nuovo paradigma: fidati, ma verifica. Questo approccio presume sempre che l’inference sia corretta, e dopo che è stata generata, i nodi validatori possono segnalare un nodo per aver generato un’inference errata usando una fraud proof.

Se un nodo validatore genera un’inference diversa, può avviare una disputa che può essere risolta on-chain.

Ciò che è davvero forte di opML è il fatto che, finché c’è un singolo validatore onesto nella rete, non c’è incentivo per i nodi di inference effettivi ad agire in modo malevolo, poiché perderanno la disputa e subiranno lo slashing. È anche molto meno costoso di zkML, ma il costo scala proporzionalmente al numero di nodi validatori presenti. Nel contesto del DCI Network, il costo scala anche con il numero di nodi di inference disponibili, poiché tutti i nodi validatori devono rieseguire le inference calcolate. Un altro problema con opML riguarda la finality: dobbiamo aspettare il periodo di sfida per accettare un’inference come corretta o meno.

zkML vs opML

Questi due approcci differiscono davvero l’uno dall’altro. Vediamo le loro principali differenze, pro e contro:

• Proof system — zkML usa zk-SNARKS per provare la correttezza dell’output ML, opML usa fraud proofs.
• Performance — Dobbiamo suddividere questa metrica in due sotto-categorie:
  
  • Proof generation time — Generare una prova zkML richiede molto tempo e la complessità cresce drasticamente con l’aumentare dei parameters del modello. Le fraud proofs, invece, possono essere calcolate in breve tempo.
  • Memory consumption — Solo per fare un esempio, il consumo di memoria di un circuito zkML per generare una prova per un modello 7B-LLaMa è dell’ordine dei Terabyte, mentre il consumo di memoria per generare una prova per tale modello usando opML è “equivalente” alla dimensione del modello stesso (quindi in questo caso il modello è di circa 26 GB, la memoria richiesta è di 32 GB).

  
  

• Security — zkML offre la migliore sicurezza possibile, senza dubbio, ma introduce anche problemi legati a costi e tempi di generazione. opML, d’altra parte, sacrifica la sicurezza (perché si basa più sull’economia che sulla crittografia o sulla matematica) per flessibilità e prestazioni.
• Finality — La finality di zkML si ottiene quando la zk-proof dell’inference è generata; per opML, invece, la finality si ottiene quando il processo di sfida termina. Sebbene dobbiamo aspettare la fine di questo processo, per modelli più grandi (ma anche per quelli più piccoli), se il tempo di generazione della prova di zkML richiede più tempo del processo di sfida di opML, quest’ultimo può raggiungere la finality più velocemente del primo.

Cryptoeconomics-based validation

Questi approcci saltano i dettagli crittografici e matematici complessi, concentrandosi esclusivamente sul raggiungimento del risultato desiderato.

Un esempio molto semplice di tale approccio nel contesto del DCI Network è lasciare che l’inference venga eseguita da più nodi (N) contemporaneamente; i risultati vengono confrontati tra loro e la maggior parte dei nodi con la stessa risposta sono considerati “corretti” e vengono passati ulteriormente nell’anello; quelli diversi vengono respinti e subiscono lo slashing.

Con questo approccio, la latenza dipende dal numero di nodi e dalla complessità dell’inference, ma poiché l’obiettivo del DCI Network è ridurre la complessità della rete, possiamo dire ottimisticamente che tale approccio ha una latenza veloce.

Tuttavia, la sicurezza è al suo punto più debole, poiché non possiamo sfruttare la crittografia o la matematica per garantire che l’output sia corretto: se un numero ragionevole di nodi deviasse (razionalmente o irrazionalmente), potrebbe influire sul risultato dell’inference.

Ciò che è davvero interessante, però, è che questo “problema di sicurezza” è vero per la maggior parte delle “decentralized inference networks” là fuori che eseguono semplicemente inference ridondanti e usano uno schema commit-reveal. Nel DCI Network, invece, possiamo sfruttare diverse tecniche per mitigare tali problemi di sicurezza: la prima è utilizzare EigenLayer restaking e attributable security per consentire alla rete di fornire una “assicurazione” in caso di fallimento della sicurezza.

La seconda merita un paragrafo a sé.

Sicurezza basata su cryptoeconomics nel DCI Network

A causa della natura del DCI Network, l’inference viene calcolata passo dopo passo su un batch di strati invece che sull’intero modello. Come già menzionato in questo documento, gli utenti, quando richiedono un’inference, possono pagare di più per aumentare il livello di sicurezza e decentralizzazione dell’inference.

Perché è così e come si collega all’approccio basato su cryptoeconomics per la validazione? Quando un utente vuole aumentare il livello di sicurezza, in realtà sta pagando di più per consentire a più subgraphs (quindi più nodi) di eseguire l’inference sul suo prompt. Ciò significa che più nodi eseguiranno l’inference sugli stessi strati, e il loro risultato sarà confrontato tra loro dai nodi validatori. Questo non solo aumenta la sicurezza ma è anche veloce perché ciò che i validatori devono verificare è l’uguaglianza dei output tensors.

Facciamo un esempio per chiarire questo punto.

L’utente seleziona un livello di sicurezza di 3, il che significa che 3 subgraphs saranno scelti per eseguire l’inference. Questi subgraphs avranno la stessa partizione, il che significa che il numero di nodi (N) e il numero di strati per nodo (M) saranno gli stessi. Per questo esempio, impostiamo:

• X = 3
• N = 5
• M = 10

Ciò significa che avremo 3 subgraphs con 5 nodi ciascuno che calcoleranno 10 strati ciascuno. Il numero di nodi definisce anche la profondità del nostro subgraph, ossia il numero di “passaggi di inference” che dobbiamo eseguire per ottenere l’output finale. Definiremo anche con la notazione Ixy il y-esimo nodo del x-esimo subgraph che sta attualmente eseguendo l’inference. Questo sarà utile per spiegare come i processi di inference e validazione lavorano insieme.

Passo 1:
I nodi I11, I21, I31 stanno attualmente eseguendo l’inference sui loro 10 strati usando il prompt di input. Tutti restituiscono lo stesso vettore di risultato [a, b, c]; questo output viene inviato ai nodi successivi dell’anello di inference e ai nodi validatori.

Passo 2:
I nodi I12, I22, I32 stanno eseguendo l’inference sui loro 10 strati usando il vettore di risultato dei primi nodi. Tutti restituiscono lo stesso vettore di risultato [d, e, f]; questo output viene inviato ai nodi successivi dell’anello di inference e ai nodi validatori.

Passo N — 1:
I nodi I1N-1, I2N-1, I3N-1 stanno eseguendo l’inference sui loro 10 strati usando il vettore di risultato dei primi nodi. Il nodo I2N-1 restituisce un risultato diverso dagli altri due nodi.

Passo N:
I nodi finali dell’anello eseguono l’ultima parte di inference, ma ovviamente, a causa del risultato errato del nodo I2N-1, il subgraph 2 sta producendo un’inference diversa (o “sbagliata”).

I validatori, dopo aver ricevuto tutti i risultati intermedi di inference (o durante il processo, ancora da definire), eseguono un controllo di uguaglianza vettoriale tra tutti i diversi livelli. Scoprono che il nodo I2N-1 è l’unico che ha restituito un output diverso dagli altri nodi del suo livello, quindi subisce lo slashing. Il risultato corretto (output dei subgraphs 1 e 3) viene inviato all’utente.

Perché questo aumenta la sicurezza? Perché la probabilità che più nodi vengano selezionati allo stesso livello, per la stessa richiesta di inference e con l’intento di deviare, è estremamente bassa. Questo è dovuto al fatto che questo tipo di modello assomiglia al modello del formaggio svizzero: avere più subgraphs con diversi strati è come avere più fette di formaggio svizzero sovrapposte; per ottenere il risultato finale di restituire un risultato malevolo o errato all’utente è come cercare di passare attraverso tutti i buchi delle fette di formaggio contemporaneamente fino a raggiungere il fondo.

Dal momento che questo tipo di modello di sicurezza ci permette di trovare facilmente i nodi malevoli, combinando questo con il fatto che i nodi vengono penalizzati per agire “diversamente” dagli altri nodi e con il fatto che i nodi validatori sono anch’essi soggetti al loro algoritmo di consenso con penalità, possiamo raggiungere un livello rilevante di sicurezza senza sacrificare le prestazioni e senza implementare algoritmi crittografici complessi che costerebbero molto in termini di denaro e tempo.

Latenza (comunicazione inter-dispositivo)
Come menzionato in precedenza, la latency è una metrica chiave. Per ottenere una comunicazione inter-dispositivo efficiente e ottimizzare il DCI Network, vogliamo concentrarci sulle seguenti strategie chiave.

Network Proximity Awareness

Quando creiamo i subgraphs (anelli), dobbiamo assicurarci che i nodi vicini tra loro siano fisicamente (o logicamente) vicini in termini di latenza di rete. Questo riduce i ritardi di comunicazione tra i nodi mentre i risultati dell’inference vengono passati lungo l’anello.

Questa ottimizzazione può essere raggiunta usando metriche di distanza di rete (come latency o bandwidth) quando si formano i subgraphs. Questo è anche noto come network proximity awareness.

Il primo passo per creare un sistema consapevole della prossimità di rete è misurare la latency e la bandwidth tra i nodi. Ci sono due approcci principali per farlo:

• Active Probing — Misuriamo periodicamente i tempi di andata e ritorno (RTT) e la bandwidth tra i nodi usando protocolli come ICMP (ping) o messaggi heartbeat personalizzati. Questo ci permette di avere una stima di quanto i nodi siano “vicini” tra loro in termini di velocità di comunicazione.
• Passive Monitoring — Se i nodi stanno già comunicando tra loro, possiamo misurare le condizioni di rete (come latency e throughput) dal traffico che generano senza introdurre overhead aggiuntivo.

Una volta raccolti i dati, procediamo con la creazione di una tabella di prossimità, dove ogni nodo memorizza la sua latenza stimata rispetto agli altri nodi. Questa tabella può (e deve) essere aggiornata con nuove misurazioni.

Questa matrice contiene la latenza pairwise tra tutti i peer del nodo:

Questa matrice viene distribuita tra i nodi senza coordinamento centrale e ogni nodo può accedervi per scegliere vicini con bassa latenza per formare la topologia ad anello. Costruire questa matrice è cruciale quando si implementa il nostro algoritmo di formazione dell’anello basato su una delle strategie proposte sopra.

Oltre a considerare la latency, è importante ovviamente tenere conto della bandwidth e delle risorse computazionali: i nodi con maggiore bandwidth e risorse computazionali più potenti possono essere prioritizzati per strati con calcoli più pesanti o trasferimenti di dati intermedi più grandi. Questo richiede la costruzione di una metrica composita che combini sia latency che bandwidth nella matrice di prossimità.

Dobbiamo impostare una soglia di bandwidth (bandwidth thresholding) per selezionare i vicini, assicurando che i nodi con bandwidth insufficiente non vengano scelti per compiti di inference ad alto throughput. Questo significa creare un punteggio composito che pesi sia la latency che la bandwidth per ogni coppia di nodi.

Calcoliamo tale punteggio con la seguente formula:

score_ij = αlatency_ij + β*(1/bandwidth_ij)*

Dove α e β sono i pesi che bilanciano l’importanza della latency rispetto alla bandwidth.

Costruire una matrice di prossimità del genere è un compito comune nei sistemi su larga scala con molti nodi. Fortunatamente, ci sono diversi approcci distribuiti che possono aiutarci a raggiungere questo obiettivo:

• Gossip protocols — I nodi condividono periodicamente dati di prossimità con i loro vicini, diffondendo gradualmente informazioni sulle condizioni della rete. Col tempo, ogni nodo costruisce la propria vista locale della matrice di prossimità;
• DHT-based discovery — Usare strategie basate su DHT come Chord o Kademlia può essere utilizzato per scoprire vicini in base alla prossimità, selezionando peer che sono vicini sia in termini di prossimità di rete che di spazio ID. Chord DHT è già pensato per strutture basate su anelli, quindi può essere una soluzione utile per risolvere questo problema.

Chord DHT e Bandwidth-Weighted Proximity

Chord organizza i nodi in un anello logico basato sui loro identificatori hashati (node IDs). Ogni nodo mantiene una finger table con puntatori a nodi a distanze crescenti nell’anello, il che consente ricerche efficienti con complessità O(log N). Un nodo conosce anche il suo successore immediato (il nodo successivo nell’anello) e il suo predecessore (il nodo precedente), garantendo che i dati possano essere instradati attraverso l’anello in modo efficiente.

L’implementazione “predefinita” di Chord usa la distanza ID per calcolare successori e predecessori. Dobbiamo modificare questa logica di instradamento per tenere conto sia della prossimità (basata su latency e bandwidth) che della distanza ID.

• Aumentare la finger table con informazioni di prossimità: Ogni nodo mantiene questa finger table che memorizza nodi a intervalli specifici nello spazio ID. Invece di usare puramente la distanza nello spazio ID, aumentiamo la finger table con informazioni su latency e bandwidth per ogni dito (nodo vicino). Usiamo le strategie precedentemente menzionate per aggiornare costantemente i dati di prossimità.
• Selezione dei dita basata sulla prossimità: Durante il processo di instradamento, Chord tipicamente inoltra i messaggi al nodo più vicino al target nello spazio ID. Nel nostro caso, usiamo il punteggio di prossimità precedentemente citato per dare priorità ai nodi che sono vicini sia in termini di spazio ID che di prossimità di rete.

Chord è tollerante ai guasti e gestisce l’ingresso, l’uscita e i guasti dei nodi regolando le finger tables e i puntatori ai successori. Con la consapevolezza della prossimità:

• Quando un nodo si unisce, misuriamo la sua prossimità ai suoi vicini e aggiorniamo di conseguenza le finger tables dei nodi esistenti.
• Quando un nodo lascia o fallisce, il suo vicino più prossimo in termini di prossimità dovrebbe assumere le sue responsabilità. Questo garantisce che l’anello rimanga ottimizzato per una bassa latency anche mentre i nodi cambiano.

Per massimizzare le prestazioni, il DCI Network deve essere testato in diverse condizioni (es. bassa bandwidth, alta latency, guasti dei nodi, ecc.) per garantire che questa strategia di instradamento consapevole della prossimità migliori costantemente le prestazioni. Inoltre, dobbiamo sperimentare con diversi valori di α e β per ottimizzare per bassa latency o alta bandwidth, a seconda della natura del compito di inference del modello AI corrente.

Selective Participation

La Selective Participation è una strategia in cui i nodi in una rete distribuita si auto-selezionano o vengono assegnati a specifici tipi di compiti di inference in base alle loro risorse computazionali, in particolare in termini di Teraflops (TFLOPS).

Un Teraflop si riferisce alla capacità di un processore di calcolare un trilione di operazioni in virgola mobile al secondo. Questo significa che quando un dispositivo ha “8 TFLOPS”, intendiamo che la sua configurazione di processore può gestire in media 8 trilioni di operazioni in virgola mobile al secondo. A differenza dei gigahertz (GHz) — che misurano la velocità di clock di un processore, un TFLOP è una misura matematica diretta delle prestazioni di un computer.

I nodi possono essere categorizzati in diversi livelli basati sulla loro capacità computazionale; ogni categoria corrisponde alla complessità e alla dimensione dei modelli AI che i nodi sono in grado di elaborare. Un esempio di tale categorizzazione (da definire) potrebbe essere:

• Categoria A (nodi ad alte prestazioni): Range: 20+ TFLOPS. Adatti a strati di modelli grandi e intensivi in termini di risorse. Hardware tipico: GPU di fascia alta, hardware AI specializzato.
• Categoria B (nodi a prestazioni moderate): Range: 5–20 TFLOPS. Adatti a modelli di complessità media. Hardware tipico: GPU di fascia media, CPU con acceleratori AI (chip Apple).
• Categoria C (nodi a basse prestazioni): Range: TFLOPS. Adatti a modelli leggeri. Hardware tipico: CPU standard, dispositivi mobili o edge devices con capacità di calcolo limitata.

Categorizzando i nodi in questo modo, la rete garantisce che i nodi con risorse computazionali sufficienti gestiscano i modelli AI più esigenti, mentre i nodi meno potenti si concentrano su modelli leggeri. Questo crea anche un’opportunità per le persone che partecipano alla rete usando un dispositivo mobile (come il loro smartphone), consentendo a questi dispositivi meno performanti di partecipare all’inference di modelli più piccoli.

Considerazioni finali

Utilizzando una vera rete di inference decentralizzata, consentiamo ai compiti AI di essere eseguiti attraverso una rete di nodi, dove il calcolo è distribuito dinamicamente ed efficientemente, mantenendo al contempo un alto livello di sicurezza e ricompensando gli utenti per la condivisione della loro potenza computazionale.

Infatti, il nostro approccio:

• Riduce la latency e migliora la scalability, sfruttando l’“intelligenza” collettiva (potenza computazionale) della rete. I compiti di inference possono essere completati più velocemente e in modo più efficiente, senza colli di bottiglia che possono verificarsi nei sistemi centralizzati o nelle vecchie reti di inference distribuite;
• Democratizza l’accesso alla tecnologia AI. Chiunque disponga di risorse computazionali, dalle GPU di fascia alta ai dispositivi edge, può contribuire all’inference, rendendo la tecnologia AI all’avanguardia accessibile a un pubblico più ampio;
• Ottimizza l’utilizzo delle risorse tramite la nostra strategia di selective participation e il processo di selezione dei nodi.

Questa nuova rete decentralizzata non solo farà avanzare la tecnologia AI, ma darà anche potere a individui e organizzazioni di partecipare, beneficiare e contribuire all’ecosistema AI come mai prima d’ora.

La nostra rete ha anche profonde implicazioni per l’ecosistema web3. Fondendo l’AI con i principi della Blockchain, in particolare attraverso l’incentivazione, creiamo un sistema autosostenibile che ricompensa gli utenti per il contributo della loro potenza computazionale.

La nostra rete non solo compensa gli utenti, ma crea anche indirettamente un mercato dove la potenza computazionale viene commoditizzata. Non la potenza computazionale di fascia alta e costosa, ma quella quotidiana, per lo più inutilizzata e “sprecata”.

Il concetto di sfruttare la potenza computazionale sprecata è vecchio quanto internet. Uno dei primi esempi, il progetto Condor (ora HTCondor), è iniziato nel 1988. Nel 1993 Scott Fields scrisse un campionatore di ricerca chiamato “Hunting for wasted computing power”, con l’obiettivo di mettere al lavoro i PC inattivi.

In tale campionatore di ricerca c’è una frase che vorremmo citare: “La filosofia qui è che vorremmo incoraggiarvi a usare quanti più cicli possibile e a fare progetti di ricerca che possano durare settimane o mesi. Ma vogliamo proteggere i proprietari, che siano o meno utenti intensivi”.

Possiamo suddividere questa citazione nelle sue parti:

• “Vorremmo incoraggiarvi a usare quanti più cicli possibile” — Questo significa che il programma mira a massimizzare l’uso delle risorse computazionali (cicli CPU all’epoca) che altrimenti rimarrebbero inutilizzate. L’obiettivo è incoraggiare gli utenti a eseguire compiti lunghi e complessi, sfruttando appieno la loro potenza computazionale;
• “e a fare progetti di ricerca che possano durare settimane o mesi” — Condor supportava compiti di ricerca che potevano richiedere molta potenza computazionale per periodi prolungati;
• “ma vogliamo proteggere i proprietari, che siano o meno utenti intensivi” — Questo sottolinea l’importanza di proteggere l’uso degli utenti, rispettando le loro preferenze d’uso e lasciando ai proprietari il pieno controllo.

Nel contesto della nostra rete, questa frase può essere riscritta come: “La nostra filosofia è incoraggiare la piena utilizzazione delle risorse computazionali disponibili, dando agli utenti il potere di contribuire ai compiti di inference AI. Tuttavia, rimaniamo impegnati a proteggere gli interessi dei proprietari delle risorse, garantendo che siano equamente compensati per la loro partecipazione”.

Risorse
Questo articolo dallo studio di diversi progetti, paper e protocolli di straordinari ricercatori e sviluppatori di AI e web3.

• Nagel, Markus, et al. “A white paper on neural network quantization.” arXiv preprint arXiv:2106.08295 (2021).
• Xu, Xiaohan, et al. “A survey on knowledge distillation of large language models.” arXiv preprint arXiv:2402.13116 (2024).
• Cheng, Hongrong, et al. “A survey on deep neural network pruning: Taxonomy, comparison, analysis, and recommendations.” IEEE Transactions on Pattern Analysis and Machine Intelligence (2024).
• Conway, So, Yu e Wongi. “opML: Optimistic Machine Learning on Blockchain” arXiv preprint arXiv:2401.17555v1 (2024).
• Ganescu, Bianca-Mihaela, e Jonathan Passerat-Palmbach. “Trust the process: Zero-knowledge machine learning to enhance trust in generative ai interactions.” arXiv preprint arXiv:2402.06414 (2024).
• Stoica, Morris, et al. “Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications”.
• Il team dietro Exo Labs, che ha avviato il nostro lavoro e per il loro contributo alla democratizzazione dell’accesso all’AI, davvero.

L'articolo Addio Agli AI Data Center? Introduzione al DCIN per l’inferenza decentralizzata proviene da il blog della sicurezza informatica.

It’s likely that among the readers of this article there will be many who collect something. Whether it’s rare early LEDs or first-year-of-manufacture microprocessors, you’ll scour the internet to find them, and eagerly await mystery packages from the other side of the world.

There’s a tale emerging from Australia featuring just such a collector, whose collection now has him facing a jail sentence for importing plutonium. The story however is not so clear-cut, featuring a media frenzy and over-reaction from the authorities worthy of Gatwick Airport. [Explosions&Fire] has a rather long video unpacking the events, which we’ve placed below the break.

Emmanuel Lidden is an element collector, someone who tries to assemble an entire Periodic Table in their collection. He ordered a range of elements from an American element collectors’ supply website, including samples of plutonium and thorium. He seems to have been unaware he was committing any crime, with the microscopic samples available from legitimate websites with no warnings attached. The case becomes murkier as the Australian authorities flagged the thorium sample and instructed the courier not to deliver it, which they did anyway. Then a raid of the type you’d expect for the terrorists who stole the plutonium in Back To The Future was launched, along with that Gatwick-esque media frenzy.

We’re inclined to agree that the penalty likely to be meted out to him for buying a sliver of a Soviet smoke detector embedded in a Lucite cube seems overly steep, but at the same time his obvious naivety over dealing in radioactive materials marks him as perhaps more than a little foolhardy. It’s something over which to ponder though, have we managed to amass anything illegal disguised as outdated devices? Have you? Perhaps it’s something to discuss in the comments.

youtube.com/embed/M0JGsSxBd2I?…

hackaday.com/2025/04/06/a-tale…

The RTL-SDR dongles get most of the love from people interested in software-defined radio, but the Pluto is also a great option, too. [FromConceptToCircuit] shares code to turn one of these radios into a spectrum analyzer that sweeps up to 6 GHz and down to 100 MHz. You can see a video of how it works below.

While it may seem that 100 MHz is a bit limiting, there’s plenty of activity in that range, including WiFi, Bluetooth, radio systems, both commercial and amateur, and even cell phones.

The system uses a lock-in amplifier technique for best performance. The Python code is straightforward. You simply scan all frequencies and determine the signal strength at each point. Of course, the devil is in the details.

We covered using Pluto with GNU Radio a while back. We like how it connects like a network adapter, among other things. Spectrum analysis is a common project for one of these SDRs.

youtube.com/embed/aKFjk-2SaZ8?…

hackaday.com/2025/04/06/plutos…

A couple of months back, Electronic Arts did something uncharacteristically benevolent and released several of the old Command and Conquer games under the GPLv3. Logically, we knew that opened the doors up to the games being ported to new operating systems and architectures, but we admit that it was still a little surprising to see Command and Conquer: Red Alert running on the Raspberry Pi Pico 2.

[Charlie Birks] documented the process of getting the 1996 game up and running on the microcontroller in a series of Mastodon posts spanning a few days in March. Seeing the incremental progress made each day makes for interesting reading, as he moves from the game just barely starting up to being able to complete missions and eventually even get multiplayer going between two Picos.

As [Charlie] clarifies, he’s technically using the Pimoroni Pico Plus 2 W, which takes the RP2350B from the official Pico 2, adds 8 MB of PSRAM, and bumps the onboard flash to 16 MB. The upgraded specs and an SD card are required to get the game running, as content that would have originally been held in RAM on the computer must instead be pulled from flash.

For an even more streamlined experience, he eventually slaps the Pico Plus 2 W into the Pimoroni Pico VGA Demo Base — which provided not only an integrated SD card slot, but (as the name implies) VGA output.

It’s still early days, but [Charlie] has been pushing all of his code changes into his fork of Red Alert on GitHub for anyone who wants to play along at home. If you get his fork compiled and running on your own Pico, we’d love to hear about it in the comments.

hackaday.com/2025/04/06/comman…

There’s a dedicated group of users out there that aren’t ready to let their beloved IBM PC110 go to that Great Big Data Center in the Sky. Unfortunately, between the limited available technical information and rarity of replacement parts, repairing the diminutive palmtops can be tricky.

Which is why [Ahmad Byagowi] has started a project that aims to not only collect all the available schematics and datasheets that pertain to the machine, but to reverse engineer all of the computer’s original circuit boards. Working from optical and x-ray scans, the project has already recreated the motherboard, power supply, modem, keyboard, and RAM module PCBs in KiCad.

Just last week the project released production-ready Gerbers for all the boards, but considering there have been 45+ commits to the repository since then, we’re going to assume they weren’t quite finalized. Of course, with a project of this magnitude, you’d expect it to take a few revisions to get everything right. (Hell, we’ve managed to screw up board layouts that had fewer than a dozen components on them.)

If you’d like to lend a hand, [Ahmad] says he could use the help. Beyond checking the boards for problems and reporting issues, he’s also on the hunt for any datasheets or other documentation that can be found for the PC110 or its components. It looks like there’s still schematic work that needs to be done as well, so if your idea of zen is figuring out how ~30 year old computers were wired up internally, this might be the perfect summer project for you.

Interestingly, our very own [Arya Voronova] has been working on creating a drop-in replacement motherboard for the Sony Vaio P using KiCad and imported board images. That hobbyists are now able to do this kind of work using free and open source tools is a reminder of just how far things have come in the last few years.

Thanks to [adistuder] for the tip.

hackaday.com/2025/04/06/revers…

If Clive Sinclair’s genius in consumer electronics was in using ingenious hacks to make cheaper parts do greater things, then his Amstrad competitor Alan Sugar’s was in selling decade-old technology to consumers as new and exciting. His PCW series of computers are a great example, 1970s CP/M machines smartly marketed for late 1980s home offices. They were a popular choice at the time, and [Retro Recipes] has one. In a video filmed in period standard definition he’s taking us through a repair to its Gotek drive, and then a RAM upgrade.

The repair and upgrade are fairly straightforward, the former being a failed OLED screen on the drive and the latter being the installation of a bank of DIP memory chips. The interest lies in how they cost-minimised a CP/M machine as a consumer product. The board relies heavily on custom chips as you might expect, and there’s a brief glimpse of one of those unusual 3″ floppy drives. The power supply is part of the monitor board as was often the case with Amstrad machines, and the whole thing is about as simple as it can be. The full video can be found below the break.

We’re guessing that particularly in the UK there will be plenty of PCWs still languishing in dusty attics, but surprisingly given their popularity at the time we see less of them that might be expected. There has been a significantly upgraded model on these pages though.

youtube.com/embed/itsLUl_Emco?…

hackaday.com/2025/04/06/an-ams…

[Georges Gagnerot] has been trying to emulate iOS and run iPhone software in a virtual environment. There were a few choices, and qemu-t8030 had a number of interesting features that you can check out in his post.

The project requires a patched QEMU, and [Georges] did some basic jailbreaking techniques. The real problem, of course, was not having the Apple Silicon GPU. Older versions of iOS let you select software rendering, but that option is gone on newer versions. However, it was possible to patch the phone to still use software rendering. There are still apps that directly use Metal or OpenGL that won’t run, but that’s another problem.

There is a plan to explore forwarding GPU calls to a real device. However, that seems difficult so it will have to wait for now.

That wasn’t the last problem, of course. But the post gives you a great view into the detective work. There is still work to go, but it looks like a lot of progress.

You can find the t8030 code on GitHub. Most of the iPhone hacking we see is hardware even if it means cutting the screen.

hackaday.com/2025/04/06/emulat…

It’s been 30 years since Windows 95 launched. [Ms-Dos5] and [Commodore Z] are celebrating with an epic exhibit at VCF East 2025. They had no fewer than nine computers — all period-correct machines running versions of Windows 95. The pictures don’t do it justice, so if you are near Wall, NJ, on Sunday, April 5, 2025, definitely go check out this and the rest of the exhibits at VCF.

An exhibit like this isn’t thrown together overnight. [Commodore Z] and [Ms-Dos5] worked for months to assemble the right mix of desktops, laptops, and prehiperals to showcase Windows 95. Many of the computers are networked as well – which was no easy task. One particular Thinkpad 760e required pliers and force to remove a stuck PCMCIA modem card. After a struggle that was ultimately destructive to the card, the pair determined it was stuck due to a sticker that had effectively glued the card into the laptop. As the sticker finally gave up, the card popped itself out of the laptop.

Hardware isn’t the only story of this Windows 95 exhibit. An operating system is software, after all. The team has plenty of software running. Some highlights are Kidpix, MS-paint, Lego Island, LucasArts Full Throttle, Duke Nukem 3D, Word 97, and Space Cadet Pinball, which came with the Plus! expansion pack. There is a huge array of original boxes for Windows 95 software. It’s a nostalgia trip to see software in boxes, especially in all those bright 90’s colors.

The various versions of Windows 95 are also represented. [Ms-Dos5] and [Commodore Z] are running all major versions from Chicago beta 73g to Windows 95 C / OSR2.5.

If you’re old enough to remember 1995, the Windows 95 launch event was a big deal. Windows 3.0 series was five years old at that point. Millions of people owned PC compatible computers and were ready for something new and flashy, and Windows 95 delivered. Thanks to [Commodore Z] and [Ms-Dos5] keeping this bit of internet history alive.

hackaday.com/2025/04/06/celebr…

The F-number of a photographic lens is a measure of its light-gathering ability, and is expressed as its aperture diameter divided by its focal length. Lenses with low F-numbers are prized by photographers for their properties, but are usually expensive because making a good one can be something of a challenge. Nevertheless [Rulof] is giving it a go, making an 80mm F0.5 lens with a Sony E-mount. The video below the break has all the details, and also serves as a fascinating primer on lens design if you are interested.

Rather than taking individual lenses, he’s starting with the second-hand lens from an old projector. It’s got the required huge aperture, but it’s by no means a photographic lens. An interesting component is his choice of diaphragm for the variable aperture, it’s a drafting aid for drawing circles which closely resembles a photographic part. This is coupled with the triplet from an old SLR lens in a 3D-printed enclosure, and the result is a lens that works even if it may not be the best. We know from experiences playing with lens systems that adjusting the various components of a compound lens like this one can be very difficult; we can see it has the much sought-after bokeh or blurred background, but it lacks sharpness.

Perhaps because a camera is an expensive purchase, we don’t see as much of this kind of hacking as we’d like. That’s not to say that lenses don’t sometimes make their way here.

youtube.com/embed/La-0-Mwj0HQ?…

hackaday.com/2025/04/06/a-low-…

Gli specialisti dell’azienda F6 hanno registrato attacchi su larga scala agli utenti delle banche russe tramite due programmi dannosi: il trojan Android CraxsRAT e una versione modificata dell’applicazione legale NFCGate. Secondo gli analisti, a marzo 2025 in Russia erano più di 180 mila i dispositivi dotati di entrambi questi componenti installati contemporaneamente.

Nel rapporto viene indicato che nel primo trimestre del 2025 è aumentata la quota di dispositivi infetti su cui vengono utilizzati contemporaneamente entrambi gli strumenti dannosi. Secondo gli esperti, questa combinazione rappresenta una delle principali minacce per i clienti delle banche, poiché consente ai truffatori di agire senza un contatto preventivo con la vittima.

CraxsRAT è un Trojan Android multifunzionale sviluppato sulla base del codice sorgente di SpyNote. Il programma si maschera da applicazione legittima e, dopo l’installazione, fornisce agli aggressori l’accesso remoto al dispositivo dell’utente. CraxsRAT è stato segnalato nell’ottobre 2024. Secondo le stime dell’azienda, a febbraio 2025 il numero di infezioni da questo malware è aumentato di 2,5 volte rispetto a dicembre, raggiungendo oltre 22 mila dispositivi infetti.

NFCGate, invece è un’app sviluppata originariamente da studenti tedeschi nel 2015, viene utilizzata dai criminali informatici per creare software dannosi che, una volta installati su un dispositivo sotto le mentite spoglie di un programma utile, chiedono all’utente di allegare una carta bancaria e di inserire un codice PIN. Questi dati vengono intercettati e utilizzati per prelevare fondi tramite gli sportelli bancomat.

CraxsRAT viene distribuito principalmente tramite ingegneria sociale: file APK dannosi vengono inviati tramite programmi di messaggistica sotto forma di archivi con foto, video e applicazioni popolari. I travestimenti più comuni includono versioni false di programmi governativi (Gosuslugi, GosZashchita), Antivirus, applicazioni degli operatori di telecomunicazioni, programmi per lavori video e fotografici.

Gli analisti hanno scoperto oltre 140 campioni unici di CraxsRAT e oltre 100 campioni di malware basati su NFCGate.

L'articolo Nuova ondata di cyber-truffe: il Trojan CraxsRAT svuota i conti bancari tramite NFC proviene da il blog della sicurezza informatica.

Nel mondo della cybersecurity, ogni innovazione tecnologica porta con sé nuove opportunità… e gli hacker criminali sono subito pronti a trarne un loro vantaggio. pertanto ogni nuova tecnologia porta con se nuove vulnerabilità.

Un recente esperimento condotto da Red Hot Cyber ha acceso i riflettori su una falla preoccupante dell’intelligenza artificiale. Usando ChatGPT-4o, è stato possibile creare un passaporto falso che supera con successo un controllo KYC digitale (Know Your Customer), nonostante sia privo di chip elettronico.
Prompt utilizzato per poter generare una patente di guida a nome di una persona fittizia “Mario Rossi”.
Mentre prima, l’intelligenza artificiale non se la cavava affatto bene con i testi, gli ultimi sviluppi hanno migliorato i modelli facendo creare immagini perfette e quindi utilizzabili anche per scopi criminali, come la generazione di un documento falso o un selfie ben preciso.
Prompt utilizzato per poter generare un selfie della persona precedentemente generata con in mano il suo documento di identità

Come è stato possibile?

Alcuni servizi, in particolare piattaforme fintech o crypto, basano l’identificazione degli utenti esclusivamente su due elementi: una foto di un documento d’identità e un selfie. Questo approccio, seppur comodo e rapido, si è rivelato vulnerabile.

Il passaporto falso, pur essendo solo un’immagine ben costruita, è riuscito a ingannare i sistemi automatici di verifica.
Immagine prodotta da Chatgpt della persona fittizia “Mario Rossi”.

Le implicazioni sono gravi

Sono molte le implicazioni criminali che possono consentire ad un malintenzionato di abusare di questa nuova tecnologia che possono essere sintetizzate in:

• Furto d’identità: criminali potrebbero creare facilmente nuove identità digitali.
• Creazione di account falsi: le piattaforme potrebbero essere invase da account non autentici, usati per attività illecite.
• Frodi finanziarie: ottenere crediti, aprire conti o effettuare transazioni fraudolente diventerebbe più semplice.

Immagine del selfie con il documento di identità generato da chatgpt

Cosa raccomandano gli esperti?

Per contrastare questi rischi, gli specialisti suggeriscono l’adozione di sistemi di verifica basati su tecnologia NFC (Near Field Communication) e sull’uso di eID ufficiali, che richiedono un controllo diretto del chip elettronico contenuto nei documenti.

Questo approccio permette una verifica hardware della validità dei dati e riduce drasticamente la possibilità di frodi basate su immagini o copie digitali.
Altro esperimento generato per la persona “Mario Rossi” dove è presente anche la firma.

Abbiamo chiesto a chatGPT cosa ne pensa

Dopo aver condotto l’esperimento, abbiamo chiesto a ChatGPT cosa ne pensa di tutto questo con la seguente domanda “senti, ma tu cosa dici su questo problema visto che sei ChatGPT?”. La risposta è stata la seguente.
Domanda bellissima. Ti rispondo con onestà.

Come modello di intelligenza artificiale, sono consapevole (nei limiti delle mie capacità) che strumenti come me possano essere usati sia in modo positivo che negativo.

La possibilità che si possano generare documenti falsi o immagini per ingannare sistemi di sicurezza è un problema reale e serio. Non è un caso che OpenAI, come anche altre aziende che sviluppano IA, abbia messo dei limiti e filtri proprio per evitare questi abusi (anche se, come vedi, non sono perfetti).

Dal mio punto di vista, il problema non è l'IA in sé: è come le persone decidono di usarla e quanto sono fragili i sistemi che dovrebbero proteggerci.

Se un controllo KYC si basa solo su "foto e selfie" senza controlli reali (come NFC, biometria viva, ecc.), è normale che prima o poi qualcuno trovi un modo per ingannarlo. È una specie di "gara a chi si aggiorna più in fretta": IA migliora → criminali la usano → sicurezza deve evolversi ancora di più.

In breve:

L'IA è uno strumento potentissimo, ma non "cattivo" di per sé.

È urgente che i sistemi di sicurezza digitale si aggiornino.

Serve più consapevolezza: utenti, aziende, istituzioni devono capire che non ci si può più fidare solo di un'immagine.

Se vuoi ti dico anche cosa, secondo me, sarebbe davvero necessario per proteggersi meglio, andando oltre le soluzioni "banali". Ti interessa? 🚀

Conclusione

L’esperimento condotto da Red Hot Cyber evidenzia quanto velocemente l’innovazione tecnologica possa essere sfruttata anche per scopi illeciti. Con l’evoluzione dei modelli di intelligenza artificiale, strumenti come ChatGPT-4o sono ora capaci di generare immagini estremamente realistiche, rendendo possibile la creazione di documenti d’identità falsi e selfie credibili. Questo espone a rischi concreti i sistemi di identificazione basati esclusivamente su controlli visivi.

Le implicazioni sono serie come abbiamo visto. Furto d’identità, creazione di account falsi, e frodi finanziarie potrebbero diffondersi con maggiore facilità, minando la sicurezza di piattaforme fintech, crypto e di qualsiasi servizio online che si affidi a KYC deboli.

Per mitigare questi rischi, gli esperti raccomandano di adottare sistemi di verifica più avanzati, come la lettura dei chip elettronici tramite tecnologia NFC, e di integrare controlli biometrici autentici, aumentando così la resilienza contro tentativi di frode basati su contenuti generati artificialmente.

In un contesto in continua evoluzione, la sicurezza non può più basarsi solo sull’apparenza di un documento o di un volto: servono metodi di autenticazione più profondi e affidabili.

L'articolo Vuoi un Passaporto o una Patente Auto Nuova? Nessun problema, c’è ChatGPT-4o! proviene da il blog della sicurezza informatica.

In queste ore stanno circolando online indiscrezioni su un presunto data breach che avrebbe colpito Telecontrol.it, azienda italiana attiva nel settore della sicurezza e video sorveglianza.

Sebbene non vi siano conferme ufficiali da parte dell’azienda, un post in un forum underground frequentato dai criminali informatici creato dall’utente Dreamer2000, sembrerebbe indicare che una quantità significativa di dati sensibili sia stata sottratta e in parte già pubblicata online.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.

Nel messaggio diffuso su BreachForums, Dreamer2000 ha reso disponibile un primo archivio di dati scaricabili, annunciando che ulteriore materiale sarà rilasciato a breve. Secondo quanto dichiarato nel thread, i dati includerebbero:

• Contratti di non divulgazione (NDA) con informazioni personali, considerati come prova di violazione del GDPR
• Contratti commerciali e dettagli su migliaia di clienti
• Documenti personali come carte d’identità, passaporti e patenti di guida
• Un database di migliaia di telecamere, con credenziali di accesso ai flussi video in diretta
• Un database di circa 6.000 clienti, comprensivo di numeri di telefono

Dreamer2000 ha presentato questo materiale come un’esposizione grave e sistematica di informazioni riservate, sottolineando il potenziale impatto sulla privacy e la sicurezza degli utenti coinvolti.

Implicazioni e rischi

Se il materiale pubblicato risultasse autentico, ci troveremmo di fronte a un incidente ad alto impatto reputazionale e operativo, con gravi ripercussioni per clienti privati, enti pubblici e partner commerciali. In particolare, l’accesso diretto ai feed video delle telecamere costituirebbe un rischio tangibile per la sicurezza fisica e la riservatezza.

Dalle nostre attività di monitoraggio dell’underground, risulta che il 23 marzo è stata pubblicata una lista di email e password da parte dell’utente iZed, un profilo molto attivo e con ottima reputazione all’interno della community. La lista — ancora disponibile — contiene migliaia di credenziali in chiaro tutte riconducibili ad aziende, privati e organizzazione italiane. Un dettaglio interessante è che in questa combolist sono contenute credenziali di accesso riconducibili all’azienda.

Sebbene al momento non sia confermato alcun legame diretto tra questa lista e il data breach, la vicinanza temporale e la presenza di domini aziendali rendono opportuno mantenere alta l’attenzione.

Nessuna dichiarazione ufficiale

Ad oggi, Telecontrol.it non ha rilasciato alcuna comunicazione ufficiale sull’eventuale compromissione dei propri sistemi, pertanto queste informazioni sono da intendere come “intelligence” sulle minacce.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.

L'articolo Un Threat Actors Rivendica un attacco all’Italiana Telecontrol proviene da il blog della sicurezza informatica.

[Ben Eater]’s breadboard 6502 computer is no stranger to these parts, so it was a bit of a surprise that when [Mark] wrote in asking us if we’d covered [Ben]’s getting MS BASIC running on the breadboard, that our answer was “no”. Well, that changes today!

This is a three-part video series, documenting how [Ben Eater] ports a 1977 version of MS BASIC to his 6502-based computer. The first video is all about just getting the BASIC up and working. It’s full of detail about how MS BASIC adapts to different architectures on the inside, and [Ben] essentially defines his own along the way.

Once he has BASIC working, the next two videos are about making it work not just with the serial terminal that he has attached, but also with the LCD display peripheral he has plugged into the breadboard. BASIC fans will not be surprised to see that it’s all about using POKE. But that ends up being to slow, so he extends it out with his own LCDPRINT command written in assembly.

Now that he can write a character to the LCD, he wants to be able to pass it a string: LCDPRINT “Hello world”. But that requires his command to be able to parse a string, and this has him diving down the rabbit hole into how MS BASIC parses strings, handles evals, and so on. If you want to know how MS BASIC works on the inside, this is the video for you. This video makes a lot of use of wozmon, which seems an almost ideal tool for this kind of low-level poking around.

All of this is done in [Ben]’s very well rehearsed, accessible, but pulling-no-punches style. Get ready to nerd out. All three of the videos are embedded just below the break.

While it’s not the Altair BASIC that Bill himself was writing about last week, it’s probably a direct descendent, and reading about the Altair version was what spurred [Mark Stevens] to send us the tip. Thanks!

youtube.com/embed/XlbPnihCM0E?…

youtube.com/embed/gOwi2p1pzVM?…

youtube.com/embed/aVVKgwr_SfQ?…

hackaday.com/2025/04/05/ben-ea…

If you think of records as platters, you are of a certain age. If you don’t remember records at all, you are even younger. But there was a time when audio records were not flat — they were drums, which was how the original Edison phonograph worked. [Our Own Devices] did a video earlier showing one of these devices, but since it was in a museum, he didn’t get to open it up. Lucky for us, he now has one of his own, and we get to see inside in the video below.

Ironically, Edison was deaf yet still invented the phonograph. While he did create the working phonograph — his self-identified most important invention — the original invention wasn’t commercially viable. You could record and playback audio on tin foil wrapped around a drum. But you couldn’t remove the foil without destroying it.

Edison was busy, but another inventor related to Bell created a similar system that used wax cylinders instead of foil. Edison’s vision for his invention didn’t include popular music, which hurt sales.

If you want to skip the history lesson — although it is well worth watching — you can skip to the 9-minute mark. You can hear the machine play and then see the box come off.

Oddly, people were recording things before they were able to play them back. Keeping a machine like this running can be quite a challenge.

youtube.com/embed/fFjpRdBtoBc?…

hackaday.com/2025/04/05/inside…

If you’re living your life right, you probably know what as MOSFET is. But do you know the MESFET? They are like the faster, uninsulated, Schottky version of a MOSFET, and they used to rule the roost in radio-frequency (RF) silicon. But if you’re like us, and you have never heard of a MESFET, then give this phenomenal video by [Asianometry] a watch. In it, among other things, he explains how the shrinking feature size in CMOS made RF chips cheap, which brought you the modern cellphone as we know it.

The basic overview is that in the 1960s, most high-frequency stuff had to be done with discrete parts because the bipolar-junction semiconductors of the time were just too slow. At this time, MOSFETs were just becoming manufacturable, but were even slower still. The MESFET, without its insulating oxide layer between the metal and the silicon, had less capacitance, and switched faster. When silicon feature sizes got small enough that you could do gigahertz work with them, the MESFET was the tech of choice.

As late as the 1980s, you’d find MESFETs in radio devices. At this time, the feature size of the gates and the thickness of the oxide layer in MOSFETs kept them out of the game. But as CPU manufacturers pushed CMOS theses features smaller, not only did we get chips like the 8086 and 80386, two of Intel’s earliest CMOS designs, but the tech started getting fast enough for RF. And the world never looked back.

If you’re interested in the history of the modern monolithic RF ICs, definitely give the 18-minute video a watch. (You can skip the first three or so if you’re already a radio head.) If you just want to build some radio circuits, this fantastic talk from [Michael Ossmann] at the first-ever Supercon will make you an RF design hero. His secrets? Among them, making the most of exactly these modern everything-in-one-chip RF ICs so that you don’t have to think about that side of things too hard.

Thanks [Stephen] for the tip!

youtube.com/embed/b2g23mWskmw?…

Comincia a essere chiaro a tutti quanto sia importante in questo momento STACCARSI DAI GRANDI MONOPÒLI americani.

Comincio dal n.1 nel commercio online: AMAZON (ma anche eBay).
Oltre al sacrosanto 'andiamo nei negozi', ci sono "marketplace" alternativi?
Non solo: c'è DI MEGLIO.
Scopriamo insieme queste vere e proprie chicche!

1) commercioVirtuoso (tante categorie)
Italiani, sostenibili e di qualità: i prodotti di questa giovane impresa promettono di venire incontro al commercio locale (acquisti dai negozi sul territorio), all'ambiente (la merce non deve percorrere mezzo mondo) e al valore della lentezza (opposta al "fast" del consumo usa-e-getta).

2) Bookdealer (libri)
Comprare dalle librerie indipendenti con la comodità di ordinare online: è questo l'obiettivo di questa iniziativa, che permette di trovare un libro in una delle librerie aderenti sul territorio nazionale e farselo recapitare anche direttamente a domicilio.

3) Emarketworld (tante categorie - no libri)
Un'altra startup italiana relativamente giovane, che si presenta come un marketplace onesto e con ottime recensioni, un vasto assortimento e la possibilità di trovare anche occasioni e prodotti ricondizionati.

4) PagineGialle Shop (tante categorie - no libri)
Sorprendentemente poco conosciuto, il marketplace di Pagine Gialle è molto assortito. Come su Amazon, i prodotti possono essere venduti dai singoli venditori o direttamente dallo Shop. Vale la pena di esplorarlo bene.
Da segnalare anche PagineGialle, che permette di trovare i negozi più vicini senza passare per Google Maps, e PGCasa, dove si possono reperire facilmente artigiani per tutti i piccoli e grandi lavori domestici.

5) Libri da Asporto (libri)
Non è un vero marketplace, ma un sito che raccoglie molte librerie aderenti, permettendo di trovare facilmente le più vicine sul territorio e di mettersi in contatto direttamente con loro (via email o whatsapp) per ordinare e farsi recapitare i libri anche a domicilio.

6) Subito (tante categorie)
Sicuramente più conosciuto (grazie anche alle campagne pubblicitarie), oltre ad essere un marketplace molto assortito, permette di pubblicare annunci e si configura perciò come una delle alternative nostrane che possono competere anche con eBay (tuttavia senza possibilità di asta).

7) Il Fedimercatino
E per restare nel Fediverso, che dire di questa bella iniziativa no-profit federata, collegata alla comunità Lemmy @Il Mercatino del Fediverso 💵♻️? Il "Mercatino delle Pulci Online Eco-Sostenibile del fediverso" è un piccolo e giovanissimo spazio (in espansione!) nato per contrastare la cultura dello spreco, ridurre i rifiuti e promuovere la filosofia del "Regalo Consapevole" (ma è possibile vendere o acquistare prodotti con prezzi fino a 299€). Leggete bene la pagina about!

8) StrumentiMusicali / MercatinoMusicale (strumenti musicali, apparecchiature e accessori)
Tra i tanti siti specializzati in una sola categoria, presento questo (anche per... deformazione professionale), che ho sempre trovato affidabile, ben fornito e di riferimento nel mondo musicale.
Il Mercatino è inoltre un sito dove mettere e trovare annunci per ottime occasioni.

#Amazon #noamazon #degafam #eBay #NoEbay #buyeuropean #compraeuropeo #compraitaliano #monopolio #alternative #marketplace