diff options
| author | murilo ijanc | 2026-03-24 21:41:06 -0300 |
|---|---|---|
| committer | murilo ijanc | 2026-03-24 21:41:06 -0300 |
| commit | f186b71ca51e83837db60de13322394bb5e6d348 (patch) | |
| tree | cd7940eaa16b83d2cde7b18123411bfb161f7ebb /pt-br/news/reed-solomon | |
| download | website-f186b71ca51e83837db60de13322394bb5e6d348.tar.gz | |
Initial commit
Import existing tesseras.net website content.
Diffstat (limited to 'pt-br/news/reed-solomon')
| -rw-r--r-- | pt-br/news/reed-solomon/index.html | 210 | ||||
| -rw-r--r-- | pt-br/news/reed-solomon/index.html.gz | bin | 0 -> 5034 bytes |
2 files changed, 210 insertions, 0 deletions
diff --git a/pt-br/news/reed-solomon/index.html b/pt-br/news/reed-solomon/index.html new file mode 100644 index 0000000..8947909 --- /dev/null +++ b/pt-br/news/reed-solomon/index.html @@ -0,0 +1,210 @@ +<!DOCTYPE html> +<html lang="pt-br"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <title>Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados — Tesseras</title> + <meta name="description" content="Um mergulho profundo na codificação de apagamento Reed-Solomon — o que é, por que o Tesseras a utiliza e os desafios de manter memórias vivas ao longo dos séculos."> + <!-- Open Graph --> + <meta property="og:type" content="article"> + <meta property="og:title" content="Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados"> + <meta property="og:description" content="Um mergulho profundo na codificação de apagamento Reed-Solomon — o que é, por que o Tesseras a utiliza e os desafios de manter memórias vivas ao longo dos séculos."> + <meta property="og:image" content="https://tesseras.net/images/social.jpg"> + <meta property="og:image:width" content="1200"> + <meta property="og:image:height" content="630"> + <meta property="og:site_name" content="Tesseras"> + <!-- Twitter Card --> + <meta name="twitter:card" content="summary_large_image"> + <meta name="twitter:title" content="Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados"> + <meta name="twitter:description" content="Um mergulho profundo na codificação de apagamento Reed-Solomon — o que é, por que o Tesseras a utiliza e os desafios de manter memórias vivas ao longo dos séculos."> + <meta name="twitter:image" content="https://tesseras.net/images/social.jpg"> + <link rel="stylesheet" href="https://tesseras.net/style.css?h=21f0f32121928ee5c690"> + + + <link rel="alternate" type="application/atom+xml" title="Tesseras" href="https://tesseras.net/atom.xml"> + + + <link rel="icon" type="image/png" sizes="32x32" href="https://tesseras.net/images/favicon.png?h=be4e123a23393b1a027d"> + +</head> +<body> + <header> + <h1> + <a href="https://tesseras.net/pt-br/"> + <img src="https://tesseras.net/images/logo-64.png?h=c1b8d0c4c5f93b49d40b" alt="Tesseras" width="40" height="40" class="logo"> + Tesseras + </a> + </h1> + <nav> + + <a href="https://tesseras.net/pt-br/about/">Sobre</a> + <a href="https://tesseras.net/pt-br/news/">Notícias</a> + <a href="https://tesseras.net/pt-br/releases/">Lançamentos</a> + <a href="https://tesseras.net/pt-br/faq/">FAQ</a> + <a href="https://tesseras.net/pt-br/subscriptions/">Inscrições</a> + <a href="https://tesseras.net/pt-br/contact/">Contato</a> + + </nav> + <nav class="lang-switch"> + + <a href="https://tesseras.net/news/reed-solomon/">English</a> | <strong>Português</strong> + + </nav> + </header> + + <main> + +<article> + <h2>Reed-Solomon: Como o Tesseras Sobrevive à Perda de Dados</h2> + <p class="news-date">2026-02-14</p> + <p>Seu disco rígido vai morrer. Seu provedor de nuvem vai pivotar. O array RAID no +seu armário vai sobreviver ao controlador, mas não ao dono. Se uma memória está +armazenada em exatamente um lugar, ela tem exatamente uma forma de se perder +para sempre.</p> +<p>Tesseras é uma rede que mantém memórias humanas vivas através de ajuda mútua. O +mecanismo central de sobrevivência é a <strong>codificação de apagamento +Reed-Solomon</strong> — uma técnica emprestada da comunicação espacial profunda que nos +permite reconstruir dados mesmo quando pedaços desaparecem.</p> +<h2 id="o-que-e-reed-solomon">O que é Reed-Solomon?</h2> +<p>Reed-Solomon é uma família de códigos corretores de erros inventada por Irving +Reed e Gustave Solomon em 1960. O caso de uso original era corrigir erros em +dados transmitidos por canais ruidosos — pense na Voyager enviando fotos de +Júpiter, ou num CD tocando apesar de arranhões.</p> +<p>A ideia-chave: se você adicionar redundância cuidadosamente calculada aos seus +dados <em>antes</em> que algo dê errado, você pode recuperar o original mesmo depois de +perder alguns pedaços.</p> +<p>Eis a intuição. Suponha que você tenha um polinômio de grau 2 — uma parábola. +Você precisa de 3 pontos para defini-lo de forma única. Mas se você avaliá-lo em +5 pontos, pode perder quaisquer 2 desses 5 e ainda reconstruir o polinômio a +partir dos 3 restantes. Reed-Solomon generaliza essa ideia para trabalhar sobre +corpos finitos (corpos de Galois), onde o "polinômio" são seus dados e os +"pontos de avaliação" são seus fragmentos.</p> +<p>Em termos concretos:</p> +<ol> +<li><strong>Divida</strong> seus dados em <em>k</em> shards de dados</li> +<li><strong>Calcule</strong> <em>m</em> shards de paridade a partir dos shards de dados</li> +<li><strong>Distribua</strong> todos os <em>k + m</em> shards em diferentes locais</li> +<li><strong>Reconstrua</strong> os dados originais a partir de quaisquer <em>k</em> dos <em>k + m</em> +shards</li> +</ol> +<p>Você pode perder até <em>m</em> shards — quaisquer <em>m</em>, de dados ou paridade, em +qualquer combinação — e ainda recuperar tudo.</p> +<h2 id="por-que-nao-simplesmente-fazer-copias">Por que não simplesmente fazer cópias?</h2> +<p>A abordagem ingênua para redundância é a replicação: faça 3 cópias, armazene-as +em 3 lugares. Isso dá tolerância a 2 falhas ao custo de 3x o seu armazenamento.</p> +<p>Reed-Solomon é dramaticamente mais eficiente:</p> +<table><thead><tr><th>Estratégia</th><th style="text-align: right">Overhead de armazenamento</th><th style="text-align: right">Falhas toleradas</th></tr></thead><tbody> +<tr><td>Replicação 3x</td><td style="text-align: right">200%</td><td style="text-align: right">2 de 3</td></tr> +<tr><td>Reed-Solomon (16,8)</td><td style="text-align: right">50%</td><td style="text-align: right">8 de 24</td></tr> +<tr><td>Reed-Solomon (48,24)</td><td style="text-align: right">50%</td><td style="text-align: right">24 de 72</td></tr> +</tbody></table> +<p>Com 16 shards de dados e 8 de paridade, você usa 50% de armazenamento extra mas +pode sobreviver à perda de um terço de todos os fragmentos. Para alcançar a +mesma tolerância a falhas só com replicação, você precisaria de 3x o +armazenamento.</p> +<p>Para uma rede que visa preservar memórias ao longo de décadas e séculos, essa +eficiência não é um luxo — é a diferença entre um sistema viável e um que se +afoga no próprio overhead.</p> +<h2 id="como-o-tesseras-usa-reed-solomon">Como o Tesseras usa Reed-Solomon</h2> +<p>Nem todos os dados merecem o mesmo tratamento. Uma memória de texto de 500 bytes +e um vídeo de 100 MB têm necessidades de redundância muito diferentes. O +Tesseras usa uma estratégia de fragmentação em três camadas:</p> +<p><strong>Small (< 4 MB)</strong> — Replicação do arquivo inteiro para 7 pares. Para tesseras +pequenas, o overhead da codificação de apagamento (tempo de codificação, +gerenciamento de fragmentos, lógica de reconstrução) supera seus benefícios. +Cópias simples são mais rápidas e mais simples.</p> +<p><strong>Medium (4–256 MB)</strong> — 16 shards de dados + 8 de paridade = 24 fragmentos no +total. Cada fragmento tem aproximadamente 1/16 do tamanho original. Quaisquer 16 +dos 24 fragmentos reconstroem o original. Distribuídos entre 7 pares.</p> +<p><strong>Large (≥ 256 MB)</strong> — 48 shards de dados + 24 de paridade = 72 fragmentos no +total. Maior contagem de shards significa fragmentos individuais menores (mais +fáceis de transferir e armazenar) e maior tolerância absoluta a falhas. Também +distribuídos entre 7 pares.</p> +<p>A implementação usa o crate <code>reed-solomon-erasure</code> operando sobre GF(2⁸) — o +mesmo corpo de Galois usado em códigos QR e CDs. Cada fragmento carrega um +checksum BLAKE3 para que a corrupção seja detectada imediatamente, não propagada +silenciosamente.</p> +<pre><code>Tessera (álbum de fotos de 120 MB) + ↓ codificar +16 shards de dados (7,5 MB cada) + 8 shards de paridade (7,5 MB cada) + ↓ distribuir +24 fragmentos entre 7 pares (diversidade de sub-rede) + ↓ quaisquer 16 fragmentos +Tessera original recuperada +</code></pre> +<h2 id="os-desafios">Os desafios</h2> +<p>Reed-Solomon resolve o problema matemático da redundância. Os desafios de +engenharia estão em tudo ao redor.</p> +<h3 id="rastreamento-de-fragmentos">Rastreamento de fragmentos</h3> +<p>Cada fragmento precisa ser localizável. O Tesseras usa uma DHT Kademlia para +descoberta de pares e mapeamento de fragmentos para pares. Quando um nó fica +offline, seus fragmentos precisam ser recriados e distribuídos para novos pares. +Isso significa rastrear quais fragmentos existem, onde estão e se ainda estão +intactos — numa rede sem autoridade central.</p> +<h3 id="corrupcao-silenciosa">Corrupção silenciosa</h3> +<p>Um fragmento que retorna dados errados é pior que um ausente — pelo menos um +fragmento ausente é honestamente ausente. O Tesseras aborda isso com +verificações de saúde baseadas em atestação: o loop de reparo periodicamente +pede aos detentores de fragmentos que provem posse retornando checksums BLAKE3. +Se um checksum não bater, o fragmento é tratado como perdido.</p> +<h3 id="falhas-correlacionadas">Falhas correlacionadas</h3> +<p>Se todos os 24 fragmentos de uma tessera caírem em máquinas no mesmo datacenter, +uma única queda de energia os elimina todos. A matemática do Reed-Solomon assume +falhas independentes. O Tesseras impõe <strong>diversidade de sub-rede</strong> durante a +distribuição: no máximo 2 fragmentos por sub-rede /24 IPv4 (ou prefixo /48 +IPv6). Isso espalha fragmentos por diferentes infraestruturas físicas.</p> +<h3 id="velocidade-de-reparo-vs-carga-na-rede">Velocidade de reparo vs. carga na rede</h3> +<p>Quando um par fica offline, o relógio começa a contar. Fragmentos perdidos +precisam ser recriados antes que mais falhas se acumulem. Mas reparo agressivo +inunda a rede. O Tesseras equilibra isso com um loop de reparo configurável +(padrão: a cada 24 horas com 2 horas de jitter) e limites de transferências +simultâneas (padrão: 4 transferências simultâneas). O jitter previne tempestades +de reparo onde cada nó verifica seus fragmentos no mesmo momento.</p> +<h3 id="gerenciamento-de-chaves-a-longo-prazo">Gerenciamento de chaves a longo prazo</h3> +<p>Reed-Solomon protege contra perda de dados, não contra perda de acesso. Se uma +tessera é criptografada (visibilidade privada ou selada), você precisa da chave +de descriptografia para tornar os dados recuperados úteis. O Tesseras separa +essas preocupações: codificação de apagamento cuida da disponibilidade, enquanto +o Compartilhamento de Segredo de Shamir (uma fase futura) cuidará da +distribuição de chaves entre herdeiros. A filosofia de design do projeto — +criptografar o mínimo possível — mantém o problema de gerenciamento de chaves +pequeno.</p> +<h3 id="limitacoes-do-corpo-de-galois">Limitações do corpo de Galois</h3> +<p>O corpo GF(2⁸) limita o número total de shards a 255 (dados + paridade +combinados). Para o Tesseras, isso não é uma restrição prática — mesmo a camada +Large usa apenas 72 shards. Mas significa que arquivos extremamente grandes com +milhares de fragmentos exigiriam um corpo diferente ou um esquema de codificação +em camadas.</p> +<h3 id="compatibilidade-evolutiva-do-codec">Compatibilidade evolutiva do codec</h3> +<p>Uma tessera codificada hoje precisa ser decodificável em 50 anos. Reed-Solomon +sobre GF(2⁸) é um dos algoritmos mais amplamente implementados na computação — +está em todo leitor de CD, em todo scanner de código QR, em toda sonda espacial. +Essa ubiquidade é em si uma estratégia de sobrevivência. O algoritmo não será +esquecido porque metade da infraestrutura do mundo depende dele.</p> +<h2 id="o-quadro-geral">O quadro geral</h2> +<p>Reed-Solomon é uma peça de um quebra-cabeça maior. Ele trabalha em conjunto com:</p> +<ul> +<li><strong>DHT Kademlia</strong> para encontrar pares e rotear fragmentos</li> +<li><strong>Checksums BLAKE3</strong> para verificação de integridade</li> +<li><strong>Reciprocidade bilateral</strong> para troca justa de armazenamento (sem blockchain)</li> +<li><strong>Diversidade de sub-rede</strong> para independência de falhas</li> +<li><strong>Reparo automático</strong> para manter a redundância ao longo do tempo</li> +</ul> +<p>Nenhuma técnica isolada faz memórias sobreviverem. Reed-Solomon garante que +dados <em>podem</em> ser recuperados. A DHT garante que fragmentos <em>podem ser +encontrados</em>. A reciprocidade garante que pares <em>querem ajudar</em>. O reparo +garante que nada disso se degrade com o tempo.</p> +<p>Uma tessera é uma aposta de que a soma desses mecanismos, rodando em muitas +máquinas independentes operadas por muitas pessoas independentes, é mais durável +que qualquer instituição isolada. Reed-Solomon é a fundação matemática dessa +aposta.</p> + +</article> + + </main> + + <footer> + <p>© 2026 Tesseras Project. <a href="/atom.xml">News Feed</a> · <a href="https://git.sr.ht/~ijanc/tesseras">Source</a></p> + </footer> +</body> +</html> diff --git a/pt-br/news/reed-solomon/index.html.gz b/pt-br/news/reed-solomon/index.html.gz Binary files differnew file mode 100644 index 0000000..d7674cf --- /dev/null +++ b/pt-br/news/reed-solomon/index.html.gz |