Finalmente ho capito come far passare gli ingegneri da principianti/intermedi a leggere grandi codebase senza sudare. La matematica è il principale ostacolo. Lo dirò chiaramente: se non hai una formazione STEM formale e lavori come ingegnere di smart contract, impegnati con @_MathAcademy_ per almeno 6 mesi. Se non puoi permettertelo, per l'amore di Satoshi, per favore completa almeno un corso di algebra gratuito online e fai in modo che Grok ti faccia da esaminatore per testare le tue conoscenze. Il livello di conoscenza matematica che hai limita il livello di complessità che puoi gestire. DeFi è finanza. La finanza è matematica. Se la tua matematica è debole, come puoi aspettarti di essere bravo in DeFi? Se non riesci a ragionare matematicamente, specialmente rapidamente, allora alcune conoscenze ti sono precluse. Esempio 1: quando si tratta di "frazioni" in Solidity, molti ingegneri si perdono perché non sanno come moltiplicare due frazioni insieme e poi normalizzare il denominatore. Quando vedono codice che fa questo, non riescono a interpretarlo. Esempio 2: gli sviluppatori non riescono a calcolare gli interessi composti e quindi non conoscono i limiti ragionevoli per quanto grande possa essere un intero. Esempio 3: gli sviluppatori non sanno cos'è un logaritmo, quindi non possono prevedere rapidamente quanto grande deve essere un intero per memorizzare un certo valore. Poi, le dimensioni degli uint nella codebase sembrano totalmente casuali. Esempio 4: a causa di una limitata conoscenza dell'algebra, alcuni sviluppatori non riescono a vedere come la formula nel whitepaper sia realmente la stessa (o abbia una piccola variazione) di quella nel codice. Finiscono per cercare di ingegnerizzare a ritroso il comportamento da zero e si perdono completamente. Esempio 5: gli sviluppatori si perdono guardando la matematica che è stata riorganizzata algebricamente per evitare un underflow temporaneo — o non sono nemmeno a conoscenza che sia un concetto. Non condivido risorse che non ho utilizzato per apparire importante. Ho provato Mathacademy — è chiaro che le persone dietro di essa comprendono profondamente come imparare in modo efficiente. Comunque, se non riesci a gestire esponenti e logaritmi, risolvi prima questo problema — poi troverai DeFi molto più facile.

Nessun rispetto, ma Londra e Parigi sono insieme a San Francisco tra i posti peggiori che ho visitato nella mia vita. - Criminali ovunque - Incredibilmente costosi senza motivo - Strade ridicolmente sporche - Il cibo è molto mediocre Dammi Singapore, Kuala Lumpur e Shanghai piuttosto che loro in qualsiasi giorno della settimana.

Probabilmente non dovrai mai dimostrare affermazioni matematiche nel tuo lavoro, ma imparare a scrivere dimostrazioni matematiche ti insegnerà a scrivere in un modo che è: inequivocabile e convincente Inequivocabile e convincente non è la stessa cosa di chiaro e persuasivo — di cui parlerò più avanti. Quando scrivi dimostrazioni matematiche, la tua scrittura deve avere una "verità sottostante" che segue le "regole del gioco" (quali trasformazioni e implicazioni sono consentite). Tuttavia, c'è una certa libertà su come esattamente "formuli" la verità sottostante — poiché non stai facendo matematica computazionale, usi l'inglese invece di simboli interamente. Tuttavia, le regole del gioco limitano fortemente ciò che puoi scrivere. Come la matematica, ogni dominio tecnico (ad es. ingegneria del software) ha "verità sottostanti" e "regole del gioco". Gli autori inesperti producono scritti correlati, ma non legati alle verità sottostanti e alle regole del gioco nel loro dominio. Ad esempio, considera la frase: "Se aumentiamo il tempo di blocco, allora la sicurezza della blockchain aumenta perché più nodi possono raggiungere il consenso." "Tempo di blocco", "quorum" e "sicurezza" sono verità sottostanti, ma la dichiarazione di relazione segue le regole del gioco? La dichiarazione suona persuasiva, ma è inequivocabile e convincente? Se hai esperienza con le dimostrazioni matematiche, saresti in grado di estrarre le assunzioni sottostanti che la dichiarazione sta facendo: - il consenso è più facile da raggiungere quando si ha più tempo - le blockchain sono più sicure quando hanno un consenso affidabile Ma quelle non sono le assunzioni precise: l'assunzione precisa è che, dato più tempo, il consenso è più probabile. Ne consegue che l'autore sta assumendo che, man mano che il tempo tende all'infinito, la probabilità di consenso si avvicina a 1. Detto in questo modo, suona come un'assunzione ragionevole? Quando letto in questo modo, un controesempio diventa più ovvio: e se molti nodi (intenzionalmente o meno) vanno offline permanentemente? Pertanto, possiamo vedere che "Se aumentiamo il tempo di blocco, allora la sicurezza della blockchain aumenta perché più nodi possono raggiungere il consenso" riflette alcune "verità sottostanti" e segue alcune "regole del gioco", ma sta anche facendo alcune importanti assunzioni non dichiarate (se queste assunzioni fossero state dichiarate nel contesto, andrebbe bene, ma non voglio deviare questo esempio con quella sfumatura). Pertanto, la dichiarazione "Se aumentiamo il tempo di blocco, allora la sicurezza della blockchain aumenta perché più nodi possono raggiungere il consenso" è chiara e persuasiva perché ciascuno dei termini che utilizza è ben compreso e non dice nulla di ovviamente sbagliato. Tuttavia, non è inequivocabile e convincente perché fa assunzioni non dichiarate sul comportamento dei nodi. Ecco una versione più convincente e inequivocabile: "Assumendo che i ritardi di rete siano l'unica cosa che impedisce il consenso, allora intervalli di blocco più lunghi migliorano la probabilità di consenso." Poiché la nuova affermazione ha un ambito ridotto (non fa affermazioni generali sulla "sicurezza" e sul comportamento atteso dei nodi), è meno inequivocabile (più precisa) e più convincente perché segue le regole del gioco (cioè la relazione tra latenza di rete e tempo di blocco). Anche se stai scrivendo in modo da semplificare le cose per un pubblico meno tecnico, devi comunque essere coerente riguardo alle regole a cui ti vincoli. I lettori ottengono un senso intuitivo di ciò che consideri una "regola del gioco" e si confonderanno se infrangi quelle regole. La cosa bella di scrivere di matematica è che le "regole del gioco" sono facili da dichiarare esplicitamente, quindi è più facile ricevere feedback quando ti allontani dal percorso. È più difficile ottenere questo feedback in discipline di livello superiore come l'ingegneria del software.