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…

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

Gli organizzatori hanno affermato di aver ricevuto quasi 250.000 adesioni alle manifestazioni contro le politiche trumpiane sulla gestione dei sussidi della previdenza sociale, i licenziamenti dei dipendenti federali, gli attacchi alle tutele dei consumatori e alle politiche anti-immigrazione e gli attacchi alle persone transgender. Le proteste sono anche contro il coinvolgimento di Elon Musk nel governo federale.

agi.it/estero/news/2025-04-05/…