W końcu odkryłem, jak niezawodnie pomóc inżynierom przejść z poziomu początkującego/średniozaawansowanego w Solidity do czytania dużych baz kodu bez większego wysiłku. Matematyka jest największą przeszkodą. Powiem to wprost — jeśli nie masz formalnego wykształcenia STEM i pracujesz jako inżynier smart kontraktów, zobowiąż się do @_MathAcademy_ na co najmniej 6 miesięcy. Jeśli nie możesz sobie na to pozwolić, dla miłości do Satoshiego, przynajmniej ukończ darmowy kurs algebry online i niech Grok będzie egzaminatorem, aby sprawdzić twoją wiedzę. Poziom wiedzy matematycznej, który posiadasz, ogranicza poziom złożoności, który możesz zrozumieć. DeFi to finanse. Finanse to matematyka. Jeśli twoja matematyka jest słaba, jak możesz oczekiwać, że będziesz dobry w DeFi? Jeśli nie potrafisz myśleć matematycznie, zwłaszcza szybko, to część wiedzy jest dla ciebie zablokowana. Przykład 1: gdy zajmują się "ułamkami" w Solidity, wielu inżynierów gubi się, ponieważ nie wie, jak pomnożyć dwa ułamki, a następnie znormalizować mianownik. Kiedy widzą kod, który to robi, nie potrafią go zinterpretować. Przykład 2: deweloperzy nie potrafią obliczyć odsetek składanych i dlatego nie znają rozsądnych granic, jak duża może być liczba całkowita. Przykład 3: deweloperzy nie wiedzą, czym jest logarytm, więc nie potrafią szybko przewidzieć, jak dużą liczbę całkowitą muszą przechować, aby zapisać określoną wartość. Wtedy rozmiary uint w bazie kodu wydają się całkowicie losowe. Przykład 4: z powodu ograniczonej algebry niektórzy deweloperzy nie widzą, jak wzór w białej księdze jest naprawdę taki sam (lub ma niewielką wariację) jak ten w kodzie. Kończą próbując odtworzyć zachowanie od podstaw i całkowicie się gubią. Przykład 5: deweloperzy gubią się, patrząc na matematykę, która została algebraicznie przekształcona, aby uniknąć tymczasowego niedoboru — lub nie są świadomi, że to w ogóle jest koncepcja. Nie dzielę się zasobami, których nie używałem dla prestiżu. Próbowałem Mathacademy — widać, że ludzie stojący za tym projektem głęboko rozumieją, jak uczyć się efektywnie. W każdym razie, jeśli nie potrafisz radzić sobie z potęgami i logarytmami, napraw to najpierw — wtedy DeFi stanie się dla ciebie znacznie łatwiejsze.

Nie chcę nikogo obrażać, ale Londyn i Paryż są obok San Francisco jednymi z najgorszych miejsc, które odwiedziłem w swoim życiu. - Kryminaliści wszędzie - Niesamowicie drogo bez powodu - Ridiculously brudne ulice - Jedzenie jest bardzo przeciętne Dajcie mi Singapur, Kuala Lumpur i Szanghaj zamiast nich w każdy dzień tygodnia.

Prawdopodobnie nigdy nie będziesz musiał udowadniać twierdzeń matematycznych w swojej pracy, ale nauka pisania dowodów matematycznych nauczy cię pisać w sposób, który jest: jednoznaczny i przekonujący Jednoznaczny i przekonujący nie jest tym samym co jasny i perswazyjny — do czego przejdę później. Pisząc dowody matematyczne, twoje pisanie musi mieć „ukrytą prawdę”, która przestrzega „reguł gry” (jakie przekształcenia i implikacje są dozwolone). Jednak istnieje pewna swoboda w tym, jak dokładnie „sformułujesz” ukrytą prawdę — ponieważ nie zajmujesz się matematyką obliczeniową, używasz angielskiego zamiast całkowicie symboli. Niemniej jednak, reguły gry mocno ograniczają to, co możesz napisać. Podobnie jak w matematyce, każda dziedzina techniczna (np. inżynieria oprogramowania) ma „ukrytą prawdę” i „reguły gry”. Niedoświadczeni autorzy produkują teksty związane z, ale nieprzywiązane do ukrytych prawd i reguł gry w swojej dziedzinie. Na przykład, rozważ zdanie: „Jeśli zwiększymy czas bloku, to bezpieczeństwo blockchaina wzrasta, ponieważ więcej węzłów może osiągnąć konsensus.” „Czas bloku”, „kworum” i „bezpieczeństwo” to ukryte prawdy, ale czy stwierdzenie o relacji przestrzega reguł gry? To stwierdzenie brzmi przekonująco, ale czy jest jednoznaczne i przekonujące? Jeśli masz doświadczenie w dowodach matematycznych, będziesz w stanie wydobyć ukryte założenia, które to stwierdzenie czyni: - konsensus jest łatwiejszy do osiągnięcia, gdy mamy więcej czasu - blockchainy są bardziej bezpieczne, gdy mają niezawodny konsensus Ale to nie są precyzyjne założenia: precyzyjnym założeniem jest to, że przy większej ilości czasu konsensus jest bardziej prawdopodobny. Z tego wynika, że autor zakłada, iż w miarę upływu czasu prawdopodobieństwo konsensusu zbliża się do 1. Powiedziane w ten sposób, czy brzmi to jak rozsądne założenie? Czytając to w ten sposób, przykład przeciwny staje się bardziej oczywisty: co jeśli wiele węzłów (celowo lub nie) przechodzi na stałe w tryb offline? Dlatego możemy zobaczyć, że „Jeśli zwiększymy czas bloku, to bezpieczeństwo blockchaina wzrasta, ponieważ więcej węzłów może osiągnąć konsensus” odzwierciedla pewne „ukryte prawdy” i przestrzega pewnych „reguł gry”, ale także czyni pewne ważne i nieujawnione założenia (jeśli te założenia byłyby ujawnione w kontekście, to w porządku, ale nie chcę odciągać tego przykładu od tej niuansy). Dlatego stwierdzenie „Jeśli zwiększymy czas bloku, to bezpieczeństwo blockchaina wzrasta, ponieważ więcej węzłów może osiągnąć konsensus” jest jasne i perswazyjne, ponieważ każdy z używanych terminów jest dobrze zrozumiany i nie mówi nic oczywiście błędnego. Jednak nie jest jednoznaczne i przekonujące, ponieważ czyni nieujawnione założenia dotyczące zachowania węzłów. Oto bardziej przekonująca i jednoznaczna wersja: „Zakładając, że opóźnienia w sieci są jedyną rzeczą, która uniemożliwia konsensus, to dłuższe interwały blokowe poprawiają prawdopodobieństwo konsensusu.” Ponieważ nowe twierdzenie ma ograniczony zakres (nie czyni żadnych szerokich twierdzeń o „bezpieczeństwie” i oczekiwanym zachowaniu węzłów), jest mniej jednoznaczne (bardziej precyzyjne) i bardziej przekonujące, ponieważ przestrzega reguł gry (tj. relacji między opóźnieniem w sieci a czasem bloku). Nawet jeśli piszesz w sposób upraszczający rzeczy dla mniej technicznej publiczności, nadal musisz być konsekwentny w regułach, do których się ograniczasz. Czytelnicy zyskują intuicyjne poczucie tego, co uważasz za „regułę gry” i będą zdezorientowani, jeśli złamiesz te zasady. Fajną rzeczą w pisaniu o matematyce jest to, że „reguły gry” są łatwe do wyrażenia w sposób explicite, więc łatwiej jest uzyskać feedback, gdy zbaczasz z kursu. Trudniej jest uzyskać ten feedback w wyższych dyscyplinach, takich jak inżynieria oprogramowania.