1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
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>
|