Finalmente descobri como fazer com que os engenheiros iniciantes/intermediários da Solidity leiam grandes bases de código sem suar a camisa. A matemática é o maior bloqueador. Vou apenas dizer - se você não tem treinamento formal em STEM e trabalha como engenheiro de contrato inteligente, comprometa-se a @_MathAcademy_ por pelo menos 6 meses. Se você não puder pagar, pelo amor de Satoshi, por favor, pelo menos conclua um curso gratuito de álgebra online e peça a Grok que sirva como examinador para testar seus conhecimentos. O nível de conhecimento matemático que você possui limita o nível de complexidade com o qual você pode lidar. DeFi é finanças. Finanças é matemática. Se sua matemática é fraca, como você espera ser bom em DeFi? Se você não consegue raciocinar matematicamente, especialmente rapidamente, então algum conhecimento está trancado longe de você. Exemplo 1: ao lidar com "frações" no Solidity, muitos engenheiros se perdem porque não sabem como multiplicar duas frações e normalizar o denominador. Quando eles veem o código fazendo isso, eles não podem interpretá-lo. Exemplo 2: os desenvolvedores não podem calcular juros compostos e, portanto, não conhecem limites razoáveis para o tamanho de um número inteiro Exemplo 3: os desenvolvedores não sabem o que é um logaritmo, portanto, não podem prever rapidamente o tamanho de um inteiro necessário para armazenar um determinado valor. Então, os tamanhos dos uint na base de código parecem totalmente aleatórios. Exemplo 4: devido à álgebra limitada, alguns desenvolvedores não conseguem ver como a fórmula no whitepaper é realmente a mesma (ou tem uma pequena variação) com a do código. Eles acabam tentando fazer engenharia reversa do comportamento do zero e ficam totalmente perdidos. Exemplo 5: os desenvolvedores se perdem olhando para a matemática que foi reorganizada algebricamente para evitar um underflow temporário - ou não estão cientes de que é mesmo um conceito. Não compartilho recursos que não usei para influência. Eu tentei a Mathacademy - está claro que as pessoas por trás dela entendem profundamente como aprender com eficiência. De qualquer forma, se você não consegue lidar com expoentes e logaritmos, corrija isso primeiro - então você achará o DeFi muito mais fácil.

Sem desrespeito, mas Londres e Paris estão ao lado de São Francisco pelos piores lugares que visitei na minha vida. - Criminosos em todos os lugares - Insanamente caro sem motivo - Ruas ridiculamente sujas - A comida é muito média Dê-me Cingapura, Kuala Lumpur e Xangai sobre eles em qualquer dia da semana.

Você provavelmente nunca terá que provar afirmações matemáticas em sua linha de trabalho, mas aprender a escrever provas matemáticas o ensinará a escrever de uma maneira que seja: inequívoco e convincente Inequívoco e convincente não é o mesmo que claro e persuasivo - o que abordarei mais tarde. Ao escrever provas matemáticas, sua escrita deve ter uma "verdade subjacente" que siga as "regras do jogo" (quais transformações e implicações são permitidas). No entanto, há alguma latitude em como exatamente você "diz" a verdade subjacente - já que você não está fazendo matemática computacional, você usa o inglês em vez de símbolos inteiros. No entanto, as regras do jogo restringem fortemente o que você pode escrever. Como a matemática, todo domínio técnico (por exemplo, engenharia de software) tem "verdade subjacente" e "regras do jogo". Autores inexperientes produzem textos relacionados, mas desvinculados das verdades e regras subjacentes do jogo em seu domínio. Por exemplo, considere a frase: "Se aumentarmos o tempo de bloco, a segurança do blockchain aumentará porque mais nós podem chegar a um consenso". "Tempo de bloqueio", "quórum" e "segurança" são verdades subjacentes, mas a declaração de relacionamento segue as regras do jogo? A declaração parece persuasiva, mas é inequívoca e convincente? Se você tiver experiência com provas matemáticas, poderá desvendar as suposições subjacentes que a declaração está fazendo: - o consenso é mais fácil de alcançar quando se tem mais tempo - Blockchains são mais seguras quando têm um consenso confiável Mas essas não são as suposições precisas: a suposição precisa é que, com mais tempo, o consenso é mais provável. Segue-se que o autor está assumindo que, à medida que o tempo vai para o infinito, a probabilidade de consenso se aproxima de 1. Dito dessa forma, parece uma suposição razoável? Quando lido dessa forma, um contra-exemplo se torna mais óbvio: e se muitos nós (intencionalmente ou não) ficarem permanentemente offline? Portanto, podemos ver que "Se aumentarmos o tempo de bloco, a segurança do blockchain aumenta porque mais nós podem chegar a um consenso" reflete algumas "verdades subjacentes" e segue algumas "regras do jogo", mas também está fazendo algumas suposições importantes e não declaradas (se essas suposições foram declaradas no contexto, tudo bem, mas não quero atrapalhar este exemplo com essa nuance). Portanto, a afirmação "Se aumentarmos o tempo de bloco, a segurança do blockchain aumenta porque mais nós podem chegar a um consenso" é clara e persuasiva porque cada um dos termos que ele usa é bem compreendido, não diz nada obviamente errado. No entanto, não é inequívoco e convincente porque faz suposições não declaradas sobre o comportamento do nó. Aqui está uma versão mais convincente e inequívoca: "Supondo que os atrasos da rede sejam a única coisa que impede o consenso, intervalos de bloco mais longos aumentam a probabilidade de consenso." Como a nova afirmação tem escopo reduzido (não faz nenhuma afirmação ampla sobre "segurança" e comportamento esperado dos nós), ela é menos inequívoca (mais precisa) e mais convincente porque segue as regras do jogo (ou seja, a relação entre latência de rede e tempo de bloqueio). Mesmo se você estiver escrevendo de forma a simplificar as coisas para um público menos técnico, ainda precisa ser consistente sobre as regras às quais se restringe. Os leitores têm uma noção intuitiva do que você considera ser uma "regra do jogo" e ficarão confusos se você quebrar essas regras. O bom de escrever sobre matemática é que as "regras do jogo" são fáceis de declarar explicitamente, por isso é mais fácil obter feedback quando você sai do caminho. É mais difícil obter esse feedback em disciplinas de nível superior, como engenharia de software.