Jeg har endelig funnet ut hvordan jeg pålitelig kan få ingeniører fra nybegynner/middels på Solidity til å lese store kodebaser uten å svette. Matematikk er den største blokkeringen. Jeg vil bare si det - hvis du ikke har noen formell STEM-opplæring og du jobber som en smart kontraktsingeniør, forplikt deg til å @_MathAcademy_ i minst 6 måneder. Hvis du ikke har råd til det, for kjærligheten til Satoshi, vennligst fullfør i det minste et gratis algebrakurs på nettet og få Grok til å fungere som sensor for å teste kunnskapen din. Nivået på matematiske kunnskaper du har begrenser kompleksitetsnivået du kan håndtere. DeFi er finans. Finans er matematikk. Hvis matematikken din er svak, hvordan forventer du å bli god på DeFi? Hvis du ikke kan resonnere matematisk, spesielt raskt, er noe kunnskap låst unna deg. Eksempel 1: når de arbeider med "brøker" i Solidity, går mange ingeniører seg vill fordi de ikke vet hvordan de skal multiplisere to brøker sammen og deretter normalisere nevneren. Når de ser kode som gjør det, kan de ikke tolke det. Eksempel 2: utviklere kan ikke beregne renters rente og kjenner derfor ikke rimelige grenser for hvor stort et heltall kan være Eksempel 3: utviklere vet ikke hva en logaritme er, så de kan ikke raskt forutsi hvor stort heltall de trenger for å lagre en bestemt verdi. Da virker uint størrelser i kodebasen helt tilfeldige. Eksempel 4: På grunn av begrenset algebra kan noen utviklere ikke se hvordan formelen i hvitboken virkelig er den samme (eller har en liten variasjon) med den i koden. De ender opp med å prøve å reversere oppførselen fra bunnen av og går seg helt vill. Eksempel 5: utviklere går seg vill når de ser på matematikk som har blitt omorganisert algebraisk for å unngå en midlertidig underflyt – eller er ikke klar over at det engang er et konsept. Jeg deler ikke ressurser jeg ikke har brukt for innflytelse. Jeg prøvde Mathacademy - det er tydelig at menneskene bak det dypt forstår hvordan man lærer effektivt. Uansett, hvis du ikke kan håndtere eksponenter og logaritmer, fiks det først – da vil du finne DeFi mye enklere.

Ingen respektløshet, men London og Paris er sammen med San Francisco for de verste stedene jeg har besøkt i mitt liv. - Kriminelle overalt - Sinnsykt dyrt uten grunn - Latterlig skitne gater - Maten er veldig middels Gi meg Singapore, Kuala Lumpur og Shanghai over dem hvilken som helst dag i uken.

Du trenger sannsynligvis aldri å bevise matematiske utsagn i arbeidet ditt, men å lære å skrive matematiske bevis vil lære deg å skrive på en måte som er: entydig og overbevisende Entydig og overbevisende er ikke det samme som klar og overbevisende – noe jeg kommer til senere. Når du skriver matematiske bevis, må skrivingen din ha en "underliggende sannhet" som følger "spillereglene" (hvilke transformasjoner og implikasjoner som er tillatt). Imidlertid er det et visst spillerom i hvordan du "formulerer" den underliggende sannheten - siden du ikke driver med beregningsmatematikk, bruker du engelsk i stedet for bare symboler. Likevel begrenser spillereglene sterkt hva du kan skrive. I likhet med matematikk har alle tekniske domener (f.eks. programvareutvikling) «underliggende sannhet» og «spilleregler». Uerfarne forfattere produserer skrifter relatert til, men ikke bundet til de underliggende sannhetene og spillereglene i sitt domene. Tenk for eksempel på setningen: "Hvis vi øker blokkeringstiden, øker sikkerheten til blokkjeden fordi flere noder kan nå konsensus." «Blokkeringstid», «quorum» og «sikkerhet» er underliggende sannheter, men følger forholdserklæringen spillereglene? Uttalelsen høres overbevisende ut, men er den entydig og overbevisende? Hvis du har erfaring med matematiske bevis, vil du være i stand til å erte ut de underliggende antagelsene utsagnet gjør: - konsensus er lettere å oppnå når man får mer tid - Blokkjeder er sikrere når de har en pålitelig konsensus Men det er ikke de nøyaktige forutsetningene: den presise antagelsen er at gitt mer tid, er konsensus mer sannsynlig. Det følger at forfatteren antar at når tiden går til det uendelige, nærmer sannsynligheten for konsensus seg 1. Sagt på den måten, høres det ut som en rimelig antagelse? Når det leses på den måten, blir et moteksempel mer åpenbart: hva om mange noder (med vilje eller ikke) går permanent offline? Derfor kan vi se at "Hvis vi øker blokkeringstiden, øker sikkerheten til blokkjeden fordi flere noder kan nå konsensus" gjenspeiler noen "underliggende sannheter" og følger noen "spilleregler", men den gjør også noen viktige og uuttalte antagelser (hvis disse antagelsene ble uttalt i sammenhengen, er det greit, men jeg vil ikke avspore dette eksemplet med den nyansen). Derfor er utsagnet "Hvis vi øker blokkeringstiden, øker sikkerheten til blokkjeden fordi flere noder kan nå konsensus" klart og overbevisende fordi hvert av begrepene det bruker er godt forstått, det sier ikke noe åpenbart galt. Den er imidlertid ikke entydig og overbevisende fordi den gjør uuttalte antagelser om nodeoppførsel. Her er en mer overbevisende og entydig versjon: "Forutsatt at nettverksforsinkelser er det eneste som hindrer konsensus, så forbedrer lengre blokkintervaller sannsynligheten for konsensus." Fordi den nye påstanden har redusert omfang (den kommer ikke med noen brede påstander om "sikkerhet" og forventet oppførsel av noder), er den mindre entydig (mer presis) og mer overbevisende fordi den følger spillereglene (dvs. forholdet mellom nettverkslatens og blokkeringstid). Selv om du skriver på en måte som forenkler ting til et mindre teknisk publikum, må du fortsatt være konsekvent med reglene du begrenser deg til. Leserne får en intuitiv følelse av hva du anser for å være en "spilleregel" og vil bli forvirret hvis du bryter disse reglene. Det fine med å skrive om matematikk er at "spillereglene" er enkle å si eksplisitt, så det er lettere å få tilbakemelding når du går av sporet. Det er vanskeligere å få denne tilbakemeldingen i disipliner på høyere nivå som programvareutvikling.