diff options
| author | murilo ijanc | 2026-03-24 21:45:05 -0300 |
|---|---|---|
| committer | murilo ijanc | 2026-03-24 21:45:05 -0300 |
| commit | 01c17c68277ff88fab812920732d9bbe9e6bb571 (patch) | |
| tree | 035398ae34263b981b621c6275835d2cc6847d57 /pt-br/news/reed-solomon | |
| parent | f186b71ca51e83837db60de13322394bb5e6d348 (diff) | |
| download | website-main.tar.gz | |
Remove old Zola-generated content, keep only the essential
landing page with about, contact, and license sections.
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 | 5034 -> 0 bytes |
2 files changed, 0 insertions, 210 deletions
diff --git a/pt-br/news/reed-solomon/index.html b/pt-br/news/reed-solomon/index.html deleted file mode 100644 index 8947909..0000000 --- a/pt-br/news/reed-solomon/index.html +++ /dev/null @@ -1,210 +0,0 @@ -<!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 differdeleted file mode 100644 index d7674cf..0000000 --- a/pt-br/news/reed-solomon/index.html.gz +++ /dev/null |