A primazia do código em execução: o ajuste necessário para preservar o design original da Internet

As sete notas anteriores de Heng.lu nesta sequência são:

Nota:52 Sobre quando o poder do registro se desvincula da responsabilidade: por que o atual modelo de coordenação dos RIR não pode sobreviver em sua forma atual
Nota:53 Sobre como os recursos numéricos da Internet não são propriedade política
Nota:56 A governança densa dos registros regionais da Internet transforma a unicidade em dupla extração
Nota:58 Da dupla extração à inversão da soberania: como as nações perdem o controle soberano para os RIR por US$100
Nota:59 A penalidade da pobreza: como o modelo RIR impõe um imposto aos pobres enquanto o chama de igualdade
Nota:61 Traição ao código em execução: como o sistema RIR voltou o consenso contra a comunidade técnica
Nota:62 Lavagem de mandato: da fantasia RIR à arquitetura de transição

Os sete ensaios anteriores não eram um programa de reforma para os Registros Regionais da Internet.

Eram uma autópsia.

Eles rastreavam a mesma patologia institucional por diferentes camadas: responsabilidade desvinculada das consequências; recursos numéricos renomeados como propriedade política; unicidade transformada em dupla extração; soberania invertida; pobreza tributada em nome da igualdade; consenso voltado contra as redes que deveria servir; e, por fim, um mandato lavado até que um agente administrativo começasse a soar como um soberano. A sequência importa porque o fracasso não foi um conselho de administração ruim, um registro ruim, uma ação judicial ou um evento de mercado incômodo. Foi um defeito sistêmico que se manifestava sob diferentes disfarces. A página do autor no CircleID agora mostra claramente essa sequência, incluindo Running-Code Betrayal e Mandate Laundering. (circleid.com)

Este ensaio não trata de transformar os RIR em governantes melhores.

Trata de explicar por que a ordem registral atual não pode ser o ponto final e por que o reparo menos disruptivo é um suplemento ao design técnico original da Internet.

Esse suplemento é a Primazia do Código em Execução (Running-Code Primacy).

A necessidade dele já não é teórica. Em uma troca recente no CircleID, John Curran apresentou a forma mais sólida do argumento do incumbente. Sua tese é que a autoridade do sistema RIR não é simplesmente um subproduto de uma coordenação técnica limitada, mas o resultado de uma cadeia histórica: o White Paper, a ICANN, a ASO, o ICP-2, a transição da supervisão da IANA e a governança multilateral contínua do setor privado. Ele afirma que a autoridade do sistema RIR resulta de operar dentro do modelo multilateral do setor privado que o governo dos Estados Unidos promoveu. (circleid.com)

Esse argumento é útil porque torna a disputa visível.

A questão já não é se houve uma delegação histórica. É claro que houve. A questão é se uma função de coordenação historicamente delegada pode depois se expandir até se tornar um mandato permanente de governança por meio da mesma maquinaria processual que ela controla. A resposta do incumbente é sim: delegação, reconhecimento, continuidade institucional e procedimento comunitário se tornam um mandato autorrenovável.

A resposta exigida pelo design técnico original da Internet é não.

A tradição original da Internet era mais estreita, mais dura e melhor. A RFC 3935 afirma que o objetivo da IETF é “fazer a Internet funcionar melhor”; fundamenta o trabalho em competência técnica, implementação no mundo real e “consenso aproximado e código em execução”. Também estabelece que, quando a IETF não é responsável por um protocolo ou função, não tenta exercer controle sobre isso. (rfc-editor.org) A RFC 7282 repete a velha frase de David Clark: “Rejeitamos: reis, presidentes e votações” e “Acreditamos em: consenso aproximado e código em execução”. (rfc-editor.org) A RFC 9592 deixa ainda mais claro o ponto antissoberano: a IETF não dirige, controla nem patrulha a Internet e não é “a polícia dos protocolos”. (rfc-editor.org)

Essa tradição nunca significou que os documentos fossem mágicos. Significava que os documentos importavam quando ajudavam os sistemas a funcionar. Significava que o processo era tolerado porque servia à implantação. Significava que uma sala só era útil quando se disciplinava em torno da realidade operacional.

A camada registral tomou emprestada essa legitimidade.

Nunca aceitou plenamente essa disciplina.

Esse é o patch que falta.

O que significa a primazia do código em execução.

A Primazia do Código em Execução significa que os sistemas de coordenação da Internet devem ser interpretados de forma estrita, tomando como referência a função técnica mínima que originalmente justificou a existência das redes em funcionamento.

A camada de recursos numéricos existe para proteger sistemas em funcionamento: unicidade, interoperabilidade, continuidade relacionada ao roteamento, afirmações de segurança, prova de controle e a semântica comum mínima necessária para que redes independentes possam trabalhar juntas.

Ela não existe para fabricar autoridade política.

Ela não existe para vigiar a moralidade comercial.

Ela não existe para transformar a geografia de um serviço em um título de propriedade.

Ela não existe para transformar uma lista de discussão em uma legislatura.

Ela não existe para permitir que um registro privado faça desaparecer ativos de rede já operacionais porque mudou sua teoria interna de políticas.

Um registro não é um Estado.

Um contato em um banco de dados não é uma procuração corporativa notarial.

Uma região de serviço não é um povo.

Uma sala de políticas não é uma legislatura.

Um registro pode descrever a realidade operacional. Ele não a cria.

Isso não é conservadorismo. A Primazia do Código em Execução não diz que os sistemas implantados nunca podem mudar. Diz que o poder institucional sobre a mudança não deve ser justificado por delegação histórica, reconhecimento circular ou procedimentos ritualísticos. Deve ser justificado por regras determinísticas que os operadores possam verificar localmente e pela adoção em sistemas em funcionamento.

A ordem correta é: especificação inicial, estado do livro-razão distribuído, validação local, implementação em execução, adoção voluntária, conjunto de compatibilidade e, então, documentação.

A ordem errada é: sala de políticas, declaração, obrigação reivindicada, rótulo de conformidade e execução operacional forçada.

O sistema RIR fracassou porque escolheu cada vez mais a segunda ordem.

A correção fundamental é esta: depois da especificação inicial, não existe uma instituição contínua da qual se peça permissão. Nenhum comitê decide se a não adoção constitui uma infração. Nenhum registro declara um participante inválido simplesmente porque ele se recusa a aceitar uma mudança posterior. Existem apenas o código, o estado do livro-razão, a validação, a adoção, a compatibilidade, a rejeição local, a bifurcação e a interoperabilidade seletiva.

Um operador que rejeita uma mudança posterior não quebra a Internet. Ele pode permanecer em um conjunto de compatibilidade mais antigo. Pode bifurcar. Pode se desconectar. Pode deixar de interoperar com participantes que adotaram regras incompatíveis. Mas não pode romper a interoperabilidade de outros que continuam executando código mutuamente compatível.

A intuição de design é a mesma que torna os livros-razões distribuídos úteis: não é necessária uma instituição permanente para decidir a validade ordinária. Os participantes validam localmente as transições de estado sob regras determinísticas. Um estado inválido não é punido por uma instituição. É ignorado pelos participantes que não o aceitam.

Esse é o patch essencial que falta na coordenação de recursos numéricos.

A falha de design estava presente desde o início.

A primeira arquitetura dos RIR pressupunha um mundo de baixo valor.

Os recursos numéricos pareciam técnicos, abundantes, administrativos e pouco conflituosos. Nesse mundo, a informalidade parecia eficiente. Listas de discussão abertas pareciam representativas. A administração baseada em contatos parecia suficiente. Contratos de responsabilidade limitada pareciam inofensivos. Um registro regional podia parecer uma simples agenda de endereços.

A escassez de IPv4 destruiu essa premissa.

Os endereços IPv4 se tornaram escassos, transferíveis, financiáveis, arrendáveis, capitalizáveis, objeto de litígios, sujeitos a sanções e integrados a redes ativas. A camada de registro deixou de estar acima de entradas administrativas. Passou a estar acima de infraestrutura produtiva. Passou a estar acima do valor dos ativos. Passou a estar acima da continuidade de clientes, da implantação em nuvem, das operações de telecomunicações, da conectividade nacional, de ordens judiciais e da alocação de capital.

A forma institucional não se ajustou para corresponder a esse novo risco.

Ela se expandiu.

O resultado é um sistema que ainda fala a linguagem da coordenação técnica enquanto exerce os efeitos de uma governança de infraestrutura. Pede aos operadores que tratem o processo registral como neutro, enquanto as decisões do registro afetam o destino comercial. Chama seus participantes de “comunidade”, embora muitos dos que suportam as consequências nunca tenham concedido representação legal clara às pessoas presentes na sala.

A NRS expõe o problema estrutural com clareza: os registros numéricos da Internet foram projetados como organismos de coordenação técnica, mas, quando a escassez de IPv4 transformou os endereços em ativos valiosos, a discricionariedade do registro se converteu em poder econômico; quando os sistemas de coordenação controlam capital, a centralização se torna um risco estrutural e a descentralização passa a ser uma questão de engenharia de sistemas, mais do que de ideologia. A NRS também propõe uma direção de design oposta: uma única Internet, infraestrutura aberta e autônoma e, como núcleo, governança descentralizada com participação humana mínima. (nrs.help)

Esse é o verdadeiro problema. A camada registral nunca foi adaptada para o momento em que uma tabela de coordenação se transformou em uma porta de acesso a ativos.

A Primazia do Código em Execução é essa adaptação.

Não é uma doutrina de “RIR melhor”.

É uma disciplina pós-RIR.

As três regras do patch

A gramática construtiva é a Nota 64 revisada: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária para Sistemas de Coordenação da Internet: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária.

Os nomes permanecem inalterados. A lógica deve ser precisa.

Especificação Inicial Mínima significa que a camada comum contém apenas regras determinísticas e verificáveis localmente necessárias para unicidade, interoperabilidade, prova de controle, segurança compartilhada e afirmações de segurança. Ela não contém preferências de modelos de negócio, teorias de preços, sentimentos políticos regionais, poderes discricionários de execução nem expansão da missão institucional.

Decisão Futura Localizada não significa que uma instituição decida quais decisões futuras são locais. Isso já reintroduziria a camada de autoridade. Significa que a especificação inicial realiza antecipadamente o trabalho de limitação. Depois da implantação, as decisões futuras ordinárias permanecem com os participantes que executam o código. Um participante pode adotar, rejeitar, bifurcar, desconectar-se ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade de outros que continuam executando regras mutuamente compatíveis.

Adoção Voluntária significa que a mudança posterior só se torna real por meio de implementação, validação, implantação e uso. Publicação não é realidade. Recomendação não é realidade. Reconhecimento institucional não é realidade. A não adoção não cria um estado de invalidez. Um participante que não adota uma mudança posterior permanece em seu conjunto de compatibilidade existente. Um participante que emite estados inválidos segundo as regras determinísticas de outro pode ser ignorado localmente. O efeito é seleção de compatibilidade, não punição institucional.

Essas três regras não reabilitam a soberania do registro.

Elas impedem que ela reapareça sob outro nome.

APNIC: a estrutura legal era o risco

A APNIC mostra a primeira falha: o mínimo nunca foi especificado de forma suficientemente rigorosa desde o início.

Não é uma história de códigos de conduta. Não é uma história de etiqueta. Não é uma história sobre se um crítico foi educado o bastante com uma instituição incumbente.

É uma história de estrutura legal.

Em março de 2023, a LARUS publicou uma revisão jurídica alertando que a estrutura de governança da APNIC criava riscos não apenas para uma empresa em Brisbane, mas para a governança da Internet em toda a região Ásia-Pacífico. A revisão afirmava que o diretor-geral da APNIC tinha poder legal final para encerrar a APNIC e destituir o Conselho Executivo eleito, e que reformas urgentes de governança eram necessárias. Também observava que a estrutura levantava dúvidas sobre a segurança da governança da Internet para mais de um bilhão de usuários na região Ásia-Pacífico. (larus.net)

O primeiro anexo, o extrato da ASIC, fornece a base corporativa. A APNIC Pty Ltd estava registrada como uma empresa privada australiana limitada por ações, registrada em Queensland. Paul Byron Wilson aparecia como diretor e secretário. As informações acionárias mostravam uma única ação ordinária emitida, e Paul Byron Wilson como titular dessa ação. (larus.net)

Essa não é uma forma normal de abrigar uma função crítica de coordenação regional da Internet.

O segundo anexo, o parecer jurídico do Dr. Peter Felter, chega a uma conclusão sobre governança. Ele descreve a estrutura pública da APNIC — membros, eleições, Conselho Executivo, diretor-geral e secretaria — como um comitê especial baseado no artigo 9.3 dos Estatutos da APNIC Pty Ltd. Afirma que a APNIC Pty Ltd foi, por 25 anos, uma empresa privada controlada por um diretor, um acionista e um secretário, todos a mesma pessoa. (larus.net)

Essa distinção importa.

A instituição pública voltada à comunidade não era a estrutura jurídica final. Era uma estrutura construída sobre uma empresa privada.

O parecer jurídico explica então por que essa distinção importa. Afirma-se que os estatutos da APNIC estão sujeitos aos Estatutos Sociais e aos poderes da corporação, de seus diretores, funcionários e membros. Sob essa interpretação, a estrutura pública da APNIC poderia ser modificada por resolução do diretor da APNIC Pty Ltd; o parecer descreve a APNIC como, na prática, um departamento da APNIC Pty Ltd. (larus.net)

O ponto mais grave do parecer não era que a APNIC fosse tecnicamente ilegal. Era que legalidade e legitimidade não são a mesma coisa. O parecer argumenta que o mecanismo de trust não resolve o problema porque os poderes do Conselho Executivo continuam derivando da resolução do diretor que estabelece o comitê especial. Também observa que a APNIC Pty Ltd é uma empresa privada com ações cuja estrutura e objeto não correspondem ao modelo de organização sem ações e sem fins lucrativos normalmente associado a um registro regional de interesse público. (larus.net)

Essa é a primeira falha de design em sua forma mais pura.

Um sistema de coordenação numérica em escala regional não deveria depender de uma estrutura que exigisse advogados para explicar por que uma empresa privada com uma única ação, um comitê especial, um trust e um conselho eleito de alguma forma se combinam em controle legítimo do registro da Internet da Ásia-Pacífico.

Uma camada de coordenação crítica deveria ser legível externamente.

Não deveria exigir confiança em documentos atrás de documentos.

Não deveria exigir que os membros descobrissem, depois de anos de dependência institucional, que a camada eleita talvez não seja a camada legal final.

Não deveria dar a aparência de governança pelos membros enquanto o poder formal reside em outro lugar.

Por isso, a Especificação Inicial Mínima deve incluir validade distribuída, e não confiança institucional. Não porque uma instituição futura precise de governança melhor, mas porque um sistema futuro pós-RIR não deve precisar dessa instituição de forma alguma.

A camada comum não deveria depender da estrutura oculta de controle de uma empresa privada. Deveria definir regras determinísticas de validação, estados de prova de controle, regras de transição de estado, regras de conflito, replicação de livros-razões, caminhos de saída, caminhos de bifurcação e conjuntos de compatibilidade. Se a APNIC desaparecer, se autocapturar, mudar sua posição legal ou se recusar a reconhecer um estado válido, a rede em funcionamento não deveria depender do reconhecimento da APNIC para saber quem controla quais recursos numéricos.

O registro não deveria ser a fonte da validade.

Essa fonte deveria ser o estado do livro-razão distribuído, validado conforme a especificação inicial.

ARIN: a política encontrou a realidade dos ativos

A ARIN mostra a segunda falha: a realidade jurídica e de mercado pode se adiantar à teoria do registro.

O evento decisivo foi a transação Nortel/Microsoft. Quando a Nortel entrou em falência, seus 666.624 endereços IPv4 se tornaram ativos valiosos no processo. Os endereços foram vendidos à Microsoft por US$ 7,5 milhões. A ARIN interveio sob a teoria de que os endereços não eram propriedade e não poderiam ser vendidos fora da política do registro. A Industry Canada apoiou essa posição. O tribunal de falências a rejeitou; a Microsoft mais tarde assinou um acordo de “legacy”; e o resultado prático foi claro: a política do registro não podia continuar sendo a única fonte da realidade quando tribunais e mercados tratavam recursos numéricos como ativos. (btw.media)

A lição importante não é que a ARIN fosse especialmente defeituosa.

A lição é que a camada registral havia entrado em uma nova categoria.

Um registro é valioso porque operadores, tribunais, compradores, vendedores, credores e redes confiam nele. Ele não se torna autoritativo negando essa dependência. Só permanece útil se refletir com precisão suficiente a realidade jurídica, de mercado e operacional.

Quando o IPv4 se tornou escasso, o processo registral virou uma interface de mercado. Regras de transferência, avaliações de necessidade, atrasos no reconhecimento e restrições regionais deixaram de ser detalhes administrativos. Tornaram-se fricções sobre ativos. A análise pública hoje descreve um livro de regras fragmentado dos RIR, no qual cinco sistemas regionais governam um mercado negociado entre aproximadamente US$ 18 e US$ 45 por endereço, com regras conflitantes capazes de imobilizar ativos, atrasar fusões e exigir estruturas corporativas separadas apenas para manter blocos de endereços. (btw.media)

Isso não é coordenação neutra.

É um efeito regulatório sem responsabilidade regulatória.

A ARIN demonstra por que a Adoção Voluntária importa. A política do registro só mantém credibilidade enquanto descreve aquilo que os atores realmente implementam, negociam, financiam, litigam e usam. Torna-se perigosa quando a publicação é tratada como suficiente para fabricar a realidade.

Um registro que se recusa a reconhecer a realidade não se torna soberano.

Ele se torna um banco de dados obsoleto.

Em um design de Primazia do Código em Execução, a lição é ainda mais clara. Tribunais e mercados não precisam de um registro incumbente para decidir se existe valor. Operadores não precisam de um comitê para saber se um bloco roteia. Os participantes precisam de regras determinísticas que permitam prova de controle, resolução de conflitos, transições de estado visíveis em um livro-razão e compatibilidade. O registro antigo pode publicar uma visão. Um cliente de software pode mostrar uma visão. Um explorador de livro-razão pode mostrar uma visão. Nenhum deles é a fonte da validade.

Não há registro para o qual migrar.

Não há registro a consultar.

Existe apenas um estado distribuído que os participantes validam, aceitam, rejeitam, bifurcam ou com o qual interoperam.

AFRINIC: quando a teoria do registro ameaçou ativos em funcionamento

A AFRINIC é o caso central porque reduziu o problema à sua essência.

A história errada é que um membro problemático paralisou um registro regional.

Esse é o enredo moral do incumbente.

A história estrutural é diferente. A AFRINIC tentou transformar uso comercial, geografia dos clientes, arrendamento, relação com os membros e interpretação interna de políticas em um poder declarado de desregistrar recursos numéricos já em funcionamento. Depois que essa afirmação foi feita, o conflito deixou de poder permanecer como uma divergência em uma sala de políticas. Tornou-se um teste para saber se um registro privado poderia usar retórica regional e silêncio normativo para ameaçar ativos integrados operacionalmente.

Os fatos não exigem exagero teatral. Relatos públicos descreveram a disputa da AFRINIC como um simples conflito comercial sobre endereços IP que se transformou na maior história de governança da Internet na África. Também observaram que a Cloud Innovation era frequentemente apresentada como vilã, enquanto material documental posterior apontava para forças destrutivas dentro da própria AFRINIC e para litígios atrasados, prolongados e continuados por representantes da AFRINIC a seu custo. (btw.media)

Isso é importante porque inverte a narrativa habitual.

O litígio não criou a falha estrutural.

Ele a expôs.

A falha relevante já estava presente quando um registro privado tratou a ausência de permissão explícita como base para controle coercitivo. O arrendamento não era uma ameaça à unicidade. A geografia dos clientes não era uma atribuição duplicada. O uso comercial não era uma falha de segurança de roteamento. Um modelo de negócio desaprovado por um registro não era um invariante global.

Mesmo assim, a interpretação do registro colocou esses elementos dentro de uma estrutura de revogação.

Esse é o momento em que coordenação se transforma em governança.

Relatos registram que a AFRINIC enviou à Cloud Innovation uma carta em março de 2021 alegando violações de políticas e ameaçando encerrar sua associação; que, em julho de 2021, a Suprema Corte das Ilhas Maurício proibiu a AFRINIC de cancelar a associação da Cloud Innovation; e que uma nova tentativa de cancelamento foi bloqueada em dezembro de 2021. (btw.media) Essa sequência não é a história de um registro protegendo calmamente a Internet. É a história da autoridade do registro encontrando o direito comum.

O colapso institucional tampouco foi causado por poder excessivo do registro. O problema mais profundo foi o bloqueio estrutural. Se um registro tem monopólio do reconhecimento sobre ativos vivos de alto valor, qualquer falha interna se torna um risco para a continuidade da Internet. Se os membros não podem sair do sistema de reconhecimento, a falha do registro se converte em poder de fazer reféns.

Um registro pode corrigir fraude registral demonstrável em seus próprios dados.

Pode impedir atribuições duplicadas enquanto o modelo registral existir.

Pode manter afirmações de segurança enquanto os participantes dependerem dele.

Mas essas são funções transitórias de uma arquitetura antiga.

Em uma arquitetura pós-RIR, essas funções não são desempenhadas por um registro. Elas são codificadas no estado de um livro-razão distribuído, em regras de prova de controle, regras de conflito e transições verificáveis localmente.

Um organismo privado não deveria transformar arrendamento em traição regional.

Não deveria transformar a geografia dos clientes em gatilho de revogação.

Não deveria tratar discordância comercial como invalidez técnica.

Não deveria transformar continuidade de ativos em permissão.

A AFRINIC demonstra a necessidade de uma Decisão Futura Localizada corretamente compreendida. Não existe um órgão central que decida que uma futura decisão comercial “pertence localmente”. Em vez disso, a especificação inicial deve garantir que essas decisões nunca entrem na camada comum. Arrendamento, geografia dos clientes, uso comercial, precificação, financiamento, composição de clientes e estratégia de implantação ficam fora das regras determinísticas de validade, a menos que afetem diretamente a unicidade, a segurança, a prova de controle ou a interoperabilidade.

Um operador não pode quebrar a interoperabilidade de outros operadores ao arrendar endereços.

Não pode quebrá-la atendendo clientes fora de uma região histórica do registro.

Não pode quebrá-la usando um modelo de negócio que o registro desaprova.

Em qualquer caso, um operador pode deixar de cumprir regras determinísticas que outros participantes executam. Nesse caso, os demais rejeitam localmente o estado inválido. Não há camada de punição. Não há tribunal de conformidade. Não há soberano regional.

Essa linha não é ideológica.

É operacional.

O problema da procuração não é um detalhe

A controvérsia eleitoral da AFRINIC tornou visível uma segunda falha: a representação.

A NRS expõe sua base de representação em termos jurídicos diretos. Afirma que os membros listados confiaram à NRS a representação em assuntos de governança dos RIR e que cada membro listado concedeu uma procuração notarial (power of attorney). (nrs.help) Durante a disputa eleitoral da AFRINIC, a NRS pediu aos membros que informassem se seus nomes apareciam nos registros de votação ou se seus votos haviam sido registrados sem sua participação, observando que esses relatos factuais seriam tratados por vias legais. (nrs.help)

Isso importa porque mostra a diferença entre representação legal e retórica comunitária.

O sistema RIR frequentemente comprime várias categorias em uma só: representante corporativo, contato de banco de dados, contato técnico, funcionário, consultor, titular de procuração, participante de políticas, usuário habitual de listas de discussão. Eles não são a mesma coisa.

Um contato em um banco de dados pode ajudar a administrar registros.

Uma procuração notarial pode autorizar representação se for válida e se a representação estiver dentro de seu alcance.

Um participante de políticas pode fornecer conhecimento especializado.

Um participante de uma lista de discussão pode expressar uma opinião.

Nenhum desses elementos se transforma automaticamente em principal legal de todas as empresas, clientes, Estados, credores, financiadores, compradores, arrendatários ou redes que suportam as consequências de uma decisão do registro.

Essa distinção só pode ser ignorada enquanto a camada comum permanecer estreita. Quando o registro reivindica poder sobre revogação, transferência, arrendamento, acesso ao mercado, sanções, continuidade de ativos ou risco de infraestrutura nacional, a representação se torna constitucional.

Uma sala não é um mandato.

Uma lista de discussão não é um povo.

Um registro de contatos não é uma procuração corporativa notarial.

Uma região de serviço não é um eleitorado soberano.

Isso não é uma questão de rigor processual.

É a diferença entre coordenação e autoridade normativa.

Um sistema de Primazia do Código em Execução evita esse problema reduzindo, em primeiro lugar, o número de decisões que exigem representação. Se a validade é determinística e local, há menos coisas para votar. Se a mudança futura é voluntária, não é necessário decidir se um não adotante está em situação irregular. Se o estado é representado em um livro-razão distribuído, não é necessário pedir a um registro incumbente que reconheça a existência contínua de um participante. Se os conjuntos de compatibilidade são explícitos, os participantes sabem com quem podem interoperar sem consultar uma sala de políticas.

O melhor problema de governança é aquele que o design do sistema elimina.

RIPE NCC e LACNIC: o clube e o ponto de estrangulamento

A RIPE NCC e a LACNIC não demonstram que alguns RIR sejam mais “civilizados” que outros. Demonstram que o modelo RIR tem duas camadas de execução além da função técnica: o clube e o ponto de estrangulamento.

O clube decide quem é respeitável. O ponto de estrangulamento decide o movimento do status registral.

A recusa da RIPE NCC em aceitar o patrocínio da LARUS para a RIPE 90 mostrou claramente a camada do clube. Um membro ofereceu patrocínio. O ecossistema do registro o rejeitou devido a uma disputa não relacionada em outra região. Isso não foi uma decisão de segurança de roteamento. Não foi uma decisão de unicidade. Não foi uma regra determinística de validação. Foi uma forma de exclusão privada por meio do controle de acesso a espaços, visibilidade, patrocínio e legitimidade social.

A LACNIC também rejeitou o patrocínio. Região diferente, mesmo padrão: o clube do registro se protege controlando salas, visibilidade e reputação.

Isso não é comunidade. É controle de acesso.

A camada de sanções é mais grave porque mostra o ponto de estrangulamento em forma jurídica. A RIPE NCC estabelece que, por estar sediada nos Países Baixos, deve cumprir as sanções da UE; quando elas se aplicam, congela registros no banco de dados RIPE, bloqueia aquisições e transferências e pode tratar casos como congelados se uma parte não puder fornecer documentação suficiente. Também realiza verificações contra listas da OFAC devido a requisitos bancários. (transparência de sanções da RIPE NCC)

Isso não é uma crítica à RIPE NCC por cumprir a lei. Uma entidade neerlandesa deve cumprir a lei neerlandesa e da UE. O problema é arquitetônico: por que uma entidade privada nos Países Baixos deveria ser o ponto central de reconhecimento da mobilidade de recursos numéricos entre vários países, operadores e sistemas jurídicos?

Sanções podem obrigar um banco. Podem obrigar uma entidade neerlandesa. Podem obrigar uma contraparte que decide não negociar. Mas não deveriam se tornar uma condição global de validade técnica para todos os demais.

Essa é a falha de design.

A mesma centralidade que permite ao clube excluir um crítico também permite que uma jurisdição congele a mobilidade registral. Uma é execução social. A outra é execução jurídica. Ambas funcionam apenas porque o registro ocupa um lugar onde a validade não deveria residir.

Isso se conecta diretamente aos três princípios.

Especificação Inicial Mínima: a respeitabilidade do clube, a elegibilidade para patrocínio, a política regional, a classificação de sanções e a reputação nunca devem entrar na camada comum. A camada comum deve conter apenas regras determinísticas de unicidade, prova de controle, resolução de conflitos, transição de estado e segurança.

Decisão Futura Localizada: o risco jurídico, a escolha da contraparte, o patrocínio, a confiança comercial e a exposição a sanções pertencem aos atores que os assumem. Uma entidade neerlandesa pode rejeitar uma transação. Um banco pode rejeitar um pagamento. Uma contraparte pode se recusar a interagir. Nada disso deve se tornar verdade registral global.

Adoção Voluntária: os participantes aceitam contrapartes executando código, validando estados e escolhendo com quem interoperar. A não adoção não é conduta indevida. A rejeição local não é invalidez global. A rejeição de um clube não deveria apagar um estado válido. Uma obrigação de sanções deve limitar o ator afetado, não reescrever o livro-razão global de recursos numéricos.

Por isso, uma arquitetura de livro-razão distribuído é necessária. Em um sistema pós-RIR, a validade ordinária não é decidida pela RIPE NCC, pela LACNIC, por uma mesa de sanções, por um comitê de reuniões ou por um escritório de patrocínio. Os participantes validam o estado localmente. As contrapartes aceitam ou rejeitam voluntariamente. As bifurcações são visíveis. Os conjuntos de compatibilidade são explícitos. O registro central desaparece como fonte da verdade.

A solução não é uma etiqueta melhor.

Não é uma fila de sanções mais transparente.

A solução é remover a validade tanto do clube quanto do ponto de estrangulamento.

Estado distribuído. Validação local. Aceitação voluntária de contrapartes. Nenhum registro como fonte de validade.

A carta da NRO: a rota de fuga para cima

A evidência mais séria não é a tentativa de extrapolação de poderes da AFRINIC.

É a resposta coletiva do sistema.

Em 2022, a Number Resource Organization escreveu ao governo das Ilhas Maurício. A carta descrevia a NRO como o organismo de coordenação dos RIR do mundo e afirmava que os RIR administram os recursos numéricos em suas respectivas regiões. Observava que os cinco registros desempenham a função de administrar recursos numéricos segundo regras adotadas regionalmente ou políticas globais adotadas por unanimidade. (nro.net)

A mesma carta criticava o litígio da Cloud Innovation, afirmava que mais de 25 ações haviam sido apresentadas, reclamava de ordens judiciais que congelaram as contas da AFRINIC e interromperam eleições e sustentava que a AFRINIC havia solicitado repetidamente às Ilhas Maurício reconhecimento como organização internacional. A NRO instava o governo a tomar medidas para preservar a independência da AFRINIC e a estabilidade da Internet na África. (nro.net)

Esse é o documento mais revelador de toda a história.

Quando um registro privado entrou em conflito com tribunais comuns, o reflexo do sistema não foi reduzir o alcance do mandato.

Não foi eliminar o bloqueio dos registros.

Não foi separar a administração registral da execução.

Não foi definir validação distribuída.

Não foi questionar se o poder unilateral de desregistrar ativos em funcionamento era ilegítimo desde o início.

O reflexo foi uma rota de fuga para cima.

Um organismo privado de coordenação não pode ser técnico quando quer discricionariedade, comunitário quando quer legitimidade, contratual quando quer tarifas, não proprietário quando quer evitar responsabilidade e quase internacional quando quer imunidade perante os tribunais.

Esse conjunto não é governança.

É uma forma sistêmica de “lavagem de mandato”.

Se os RIR querem privilégios de direito público, devem aceitar responsabilidade de direito público. Se querem flexibilidade de direito privado, devem aceitar litígio de direito privado. O que não podem exigir de forma coerente é discricionariedade privada, importância de infraestrutura pública, baixa responsabilidade, representação fraca, status monopolista e imunidade quase diplomática ao mesmo tempo.

Esse é o caminho do colapso.

A Primazia do Código em Execução o rejeita.

Quando um registro enfrenta resistência jurídica, não deve escapar para cima em busca de imunidade. A arquitetura deve se contrair para baixo, reduzindo-se à função estrita de código em execução que originalmente a justificou.

Menos soberania.

Nenhum registro como fonte de validade.

Menos execução.

Mais validação distribuída.

A revisão do ICP-2 não é suficiente

O sistema atual reconhece que algo se rompeu.

A página de comentários públicos da ICANN sobre o segundo rascunho do documento de governança dos RIR afirma que a proposta estabeleceria regras e critérios para reconhecer novos RIR, obrigações operacionais e requisitos para os RIR existentes, além de regras de desreconhecimento; se adotada, substituiria o ICP-2. A mesma página informa que o processo foi iniciado depois que a NRO solicitou à ASO que propusesse atualizações para dar ao sistema RIR maior prestação de contas perante a comunidade da Internet. (icann.org)

Isso pode ser necessário como medida de continuidade.

Não é suficiente como teoria de legitimidade.

Regras de reconhecimento e desreconhecimento respondem a uma pergunta tardia: quando um registro falhou o suficiente para ser eliminado?

A pergunta anterior é mais importante: por que um registro deveria ter poder suficiente para falhar catastroficamente em primeiro lugar?

Um sucessor do ICP-2 que apenas endureça reconhecimento, auditoria, transição e desreconhecimento pode melhorar a higiene institucional enquanto preserva o erro de categoria. Continua assumindo que o RIR é a forma soberana primária de coordenação dos recursos numéricos.

A Primazia do Código em Execução propõe um conjunto diferente de perguntas.

Como a Internet continua se um RIR colapsar?

Como as atribuições de recursos numéricos permanecem verificáveis sem a permissão de uma entidade incumbente?

Como a unicidade sobrevive sem discricionariedade monopolista?

Como impedir que os registros se tornem ferramentas de execução coercitiva?

Como manter as decisões comerciais fora da validade determinística, exceto quando houver um invariante global real em risco?

Como a coordenação permanece utilizável sem um registro autoritativo?

Como um operador valida o estado ordinário sem consultar um organismo permanente?

Como evitar que a rejeição se transforme em um rótulo de infração?

Essas não são perguntas de reforma.

São perguntas pós-RIR.

Por que este é o patch do design original

O problema não é se alguém gosta ou não dos registros incumbentes.

O problema é saber se a camada de recursos numéricos ainda obedece à disciplina de design que tornou a Internet possível: regras comuns mínimas, validação local, adoção voluntária e código em execução.

A Primazia do Código em Execução não é uma estratégia de relações públicas nem um compromisso institucional. É o reparo técnico implícito no design original. Se a Internet foi construída para rejeitar reis, presidentes e votações como fontes da verdade técnica, então a camada de recursos numéricos não pode recriar essas formas por meio de processos registrais, delegação histórica ou teatro comunitário.

O consenso sozinho pode se tornar ritual. O código em execução sozinho pode ser subordinado se a camada registral for colocada acima como fonte de reconhecimento. A regra que falta é interpretativa e arquitetônica: quando o processo institucional entra em conflito com a função técnica mínima exigida pelos sistemas em funcionamento, o código em execução tem prioridade; e, quando uma mudança posterior é proposta, ela só se torna real por meio da adoção voluntária dos participantes que executam as regras de validação.

É assim que o design original é preservado, e não abandonado.

A Internet foi importante porque se tornou o primeiro sistema global de comunicações que não exigia permissão prévia de um único soberano, ministério, igreja, corporação ou guardião. Se essa conquista continua digna de defesa, a camada de recursos numéricos não pode se tornar a exceção que invalida a regra.

Um sistema construído para evitar reis não pode permitir que um contador aspire a ser um.

O patch restaura a hierarquia original: código primeiro, operadores primeiro, validação determinística primeiro, estado distribuído primeiro; instituições, se existirem durante a transição, apenas como artefatos não autoritativos, nunca como fontes de validade.

O que a coordenação pós-RIR exige

A coordenação pós-RIR não significa caos.

Significa que a camada comum se torna mais estreita, mais objetiva, mais determinística e mais distribuída que o monopólio atual dos RIR.

Não há registro para o qual migrar.

Não há novo registro para coroar.

Não há novo sacerdócio.

Existe um livro-razão distribuído do estado dos recursos numéricos, com regras determinísticas de validação, mecanismos de prova de controle, tratamento de conflitos, conjuntos de compatibilidade, histórico de transições de estado e verificação local pelos participantes.

A camada comum deve preservar a unicidade dos identificadores, a prova de controle, o estado de transferência, o estado de delegação, afirmações de segurança relacionadas ao roteamento, auditabilidade, metadados de conflito e visibilidade das bifurcações.

A camada dos operadores deve controlar uso comercial, arrendamento, geografia dos clientes, práticas de roteamento, financiamento, seleção de contrapartes e regras de negócio que não sejam invariantes.

A camada de adoção deve determinar o que se torna real. Uma regra de coordenação só importa se os operadores puderem implementá-la, as contrapartes puderem aceitá-la, os mercados puderem confiar nela, os tribunais puderem entendê-la e a interoperabilidade for mantida sem transformar o reconhecimento do incumbente na única fonte da realidade.

A camada de execução não deve se fundir à camada de estado. Um livro-razão distribuído pode registrar estado. Pode validar transições. Pode expor conflitos. Pode tornar a prova portátil. Não deve se tornar simultaneamente promotor, juiz, autoridade sancionadora, regulador de mercado, moralista comercial e custodiante de ativos.

O mais importante é entender corretamente a portabilidade.

Em um mundo de livro-razão distribuído, portabilidade não significa passar de um registro para outro. Isso ainda é pensamento registral. Não há registro para o qual migrar. A prova de controle do titular, o histórico de estado e a capacidade de transferência não ficam presos dentro de um banco de dados incumbente. Eles existem em um estado compartilhado verificável que os participantes validam localmente e que as contrapartes aceitam voluntariamente.

Sem isso, cada registro é um ponto de bloqueio.

Com isso, o registro deixa de ser fonte de validade.

Portanto, a coordenação pós-RIR precisa de quatro propriedades de design.

Primeiro, validade determinística. Um participante deve poder saber se uma transição de estado, prova, delegação, transferência ou afirmação é válida aplicando localmente a especificação.

Segundo, conjuntos de compatibilidade. Se os participantes adotarem regras futuras diferentes, o sistema deve descrever claramente os limites de compatibilidade, em vez de tratar a dissidência como infração.

Terceiro, prova distribuída de controle. Um titular não deve “mover” seus recursos para outro registro; deve demonstrar controle por meio de um estado válido no livro-razão que qualquer contraparte possa verificar sem aprovação do incumbente.

Quarto, visibilidade das bifurcações. Se os conjuntos de regras divergirem, a divergência deve ser explícita. Os participantes decidem qual conjunto de compatibilidade executar e com quais contrapartes interagir. Uma bifurcação pode isolar participantes, mas não dá a uma das partes poder institucional para apagar a outra.

Isso não é um argumento a favor de cinco monopólios melhores.

É um argumento contra o monopólio como fonte de validade.

Por que o caminho do fracasso é previsível

Se nada mudar, o caminho do fracasso é claro.

Primeiro, mais disputas passarão das salas de políticas para os tribunais. Ativos escassos atraem escrutínio jurídico. Será pedido aos tribunais que congelem contas, preservem registros, bloqueiem eleições irregulares, nomeiem administradores judiciais, reconheçam transferências ou determinem quem pode agir em nome de um registro.

Segundo, os Estados deixarão de tratar os RIR como associações técnicas inofensivas. A continuidade do endereçamento afeta conectividade nacional, sanções, aplicação da lei, resiliência das telecomunicações, infraestrutura em nuvem e segurança econômica. Nenhum Estado aceitará indefinidamente uma entidade privada estrangeira como ponto superior não questionado da continuidade das comunicações nacionais.

Terceiro, os operadores contornarão a autoridade do registro quando possível. Se os registros se tornarem políticos, inseguros, não representativos ou desconectados da realidade dos ativos, os operadores recorrerão a contratos privados, transferências respaldadas por litígios, certificações alternativas, reconhecimento nacional ou à realidade de roteamento de fato.

Quarto, as camadas da ICANN e da NRO se sentirão tentadas a centralizar. Isso produziria uma versão mais densa do mesmo problema, a menos que o mandato em si seja reduzido.

Quinto, os governos serão tentados a nacionalizar. Isso seria previsível e perigoso. Se os registros privados reivindicarem autoridade quase soberana sem responsabilidade pública, os Estados acabarão reivindicando soberania. O resultado pode ser fragmentação, retaliações, registros conflitantes e pressão política sobre o roteamento.

A Internet não falha apenas quando os pacotes deixam de circular.

Ela também falha quando as instituições que descrevem quem pode usar identificadores perdem a confiança dos operadores que fazem esses pacotes circularem.

Um livro-razão distribuído não resolve todos os problemas políticos. Mas faz algo mais importante: elimina o registro permanente como fonte ordinária de validade. Isso reduz a superfície de ataque. Reduz o poder institucional de manter reféns. Converte divergências futuras em seleção de compatibilidade, em vez de guerra administrativa.

A pergunta muda

O sistema antigo pergunta: quem tem o mandato?

Essa é a pergunta errada.

A pergunta melhor é: o que o código em execução realmente exige?

Esta regra protege a unicidade?

Preserva a interoperabilidade?

Corrige fraude registral demonstrável por evidência determinística?

Protege a segurança relacionada ao roteamento?

Mantém a precisão da prova de controle?

Permite validação local?

Elimina a dependência de um único incumbente?

Descreve a realidade adotada ou declara uma obrigação não adotada?

Um participante pode rejeitá-la sem ser rotulado como inválido?

Um participante pode verificar a validade ordinária sem pedir um estado a um registro?

Uma contraparte pode aceitar ou rejeitar o estado voluntariamente?

Uma bifurcação pode ocorrer sem que uma das partes seja eliminada por uma instituição?

Se a resposta não estiver ligada à necessidade determinística do código em execução, esse poder não deveria residir na camada comum.

Isso é a Primazia do Código em Execução.

Para discussão

Esta proposta está aberta à discussão. Não é uma solução final.

O próximo passo deveria ser um Internet-Draft sério ou um documento no formato BCP que defina a Primazia do Código em Execução para sistemas de coordenação da Internet, começando pelos recursos numéricos. O rascunho não deveria perguntar como reabilitar o monopólio dos RIR. Deveria perguntar como construir coordenação pós-RIR por meio de estado em um livro-razão distribuído, validação determinística, adoção voluntária, aceitação por contrapartes e conjuntos de compatibilidade explícitos.

Ele deveria ser avaliado por operadores, advogados, economistas, engenheiros de protocolos, especialistas em segurança de roteamento, participantes de mercado, governos e críticos.

O rascunho deveria fazer perguntas difíceis.

Quais são os invariantes globais?

Quais regras de validação são determinísticas?

Quais transições de estado devem ser visíveis globalmente?

Quais poderes antigos do registro são resíduos históricos?

Quais decisões pertencem aos operadores?

Quais decisões não exigem representação porque nunca deveriam entrar na camada comum?

Qual é o caminho da rejeição?

Qual é o caminho da bifurcação?

Qual é o caminho da rejeição local?

Como um titular demonstra controle sem um registro incumbente?

Como uma contraparte verifica o estado sem um registro?

A Internet pode continuar se um RIR colapsar?

Os recursos numéricos podem continuar únicos sem a permissão de um incumbente?

Um participante pode validar o estado ordinário sem uma instituição permanente?

Um processo de políticas pode distinguir entre um invariante do código em execução e a vontade institucional?

A antiga camada registral pode desaparecer sem perder o estado verificável?

Um registro pode descrever a realidade sem se tornar soberano sobre ela?

Qualquer pessoa interessada pode entrar em contato comigo pelo LinkedIn. Pesquisadores sérios, autores técnicos, instituições ou especialistas em políticas que queiram ajudar a transformar isto em um primeiro Internet-Draft e, eventualmente, em uma RFC ou discussão BCP, se a comunidade considerar útil, podem entrar em contato comigo. A LARUS Foundation e eu estamos dispostos a apoiar e financiar pesquisas sérias nessa direção.

O sistema RIR fracassou em seu design inicial porque nunca perguntou o que o código em execução realmente exigia.

Perguntou quem podia falar na sala.

O próximo sistema deve inverter essa ordem.

Não é lavagem de mandato.

Não é traição ao código em execução.

Primazia do Código em Execução.

Apêndice: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária para Sistemas de Coordenação da Internet

Nota 64

Resumo

Este documento descreve um padrão de design para sistemas de coordenação da Internet cujo objetivo é fornecer pontos de referência técnicos compartilhados sem criar uma autoridade contínua acima dos participantes que executam o sistema. Ele define três princípios relacionados: Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária.

Nesse modelo, a Especificação Inicial define apenas as regras determinísticas e verificáveis localmente necessárias para unicidade, interoperabilidade, prova de controle, segurança compartilhada e segurança. Depois da Especificação Inicial, mudanças futuras não são aprovadas por um organismo central. Elas são adotadas, ignoradas, bifurcadas ou abandonadas pelos participantes que executam código.

O padrão de design previsto é um livro-razão distribuído de estado válido, ou um mecanismo equivalente de estado verificável distribuído, e não uma hierarquia de registros. Não existe um registro permanente que decida a validade ordinária. Os participantes validam o estado localmente, aceitam contrapartes voluntariamente e decidem quais conjuntos de compatibilidade executar.

A não adoção não é uma infração. Um participante que não adota uma mudança posterior permanece em seu conjunto de compatibilidade existente. Um participante que emite estados inválidos segundo as regras determinísticas aceitas por outro participante pode ser ignorado localmente por esse participante. O efeito é seleção de compatibilidade, bifurcação, isolamento ou interoperabilidade seletiva, não punição institucional.

Este documento não define um protocolo de rede (wire protocol). Ele especifica uma Boa Prática Atual (BCP) para o design de protocolos, sistemas de identificadores, livros-razões distribuídos e mecanismos de coordenação que não devem se tornar instituições permanentes de governança.

1. Introdução

Muitos sistemas da Internet começam com um propósito técnico limitado: permitir que atores independentes interoperem por meio de um ponto de referência comum, um espaço de identificadores, uma regra de validação, um estado de livro-razão ou um registro compartilhado de prova de controle. Com o tempo, esses sistemas costumam acumular autoridade que não era necessária para a interoperabilidade inicial.

Isso normalmente ocorre em três passos.

Primeiro, perguntas futuras são incorporadas à camada fundacional antes de serem tecnicamente necessárias.

Segundo, decisões que deveriam ser tomadas pelos participantes que executam seus próprios sistemas passam a depender do reconhecimento, da interpretação ou de decisões de status por parte de um organismo permanente.

Terceiro, publicação, registro, recomendação ou aprovação processual são tratados como suficientes para criar obrigações operacionais, mesmo quando os participantes não adotaram a mudança nos sistemas em execução.

O resultado é um sistema frágil. Uma camada de referência técnica se torna uma camada de governança. Um registro se torna um ponto de controle. Um artefato de coordenação se torna uma fonte de controle futuro.

Este documento propõe uma disciplina de design diferente:

Especificação Inicial Mínima: definir apenas as regras determinísticas comuns necessárias para interoperabilidade básica, unicidade, prova de controle, segurança compartilhada e segurança.

Decisão Futura Localizada: depois da Especificação Inicial, manter as decisões futuras com os participantes que executam código. Um participante pode adotar, rejeitar, bifurcar, desconectar-se ou interoperar seletivamente. Nenhum participante pode alterar a interoperabilidade de outros participantes que continuam executando regras mutuamente compatíveis.

Adoção Voluntária: tornar mudanças posteriores reais apenas por meio da implementação, operação, validação e adoção pelos participantes que executam código.

Esses princípios estão relacionados. Um sistema que especifica demais desde o início pré-carrega o controle futuro na camada comum. Um sistema que mantém uma camada de reconhecimento contínuo permite que a autoridade reapareça depois da implantação. Um sistema que trata a publicação como realidade transforma documentação em mandato.

A intuição de design é simples: a validade deve ser determinada por regras determinísticas que os participantes possam verificar localmente contra um estado compartilhado. Um participante pode adotar uma mudança posterior, rejeitá-la, bifurcar, desconectar-se ou interoperar seletivamente. No máximo, pode sair de um conjunto de compatibilidade. Não pode, ao rejeitar uma mudança, romper a interoperabilidade de outros participantes que continuam executando regras mutuamente compatíveis.

Essa é a lição geral do design de livros-razões distribuídos: regras de consenso são aplicadas por participantes que executam código de validação e decidem qual estado aceitam, e não por uma instituição situada acima deles.

2. Escopo

Este documento se aplica a sistemas de coordenação da Internet, incluindo, entre outros, sistemas de identificadores, estruturas de nomes e numeração, mecanismos de extensão de protocolos, sistemas de prova de controle, sistemas de portabilidade, livros-razões distribuídos e outras arquiteturas nas quais atores independentes dependem de um ponto de referência técnico comum.

Este documento não argumenta contra regras comuns. Argumenta que regras comuns devem ser determinísticas, mínimas, verificáveis localmente e limitadas ao que o sistema realmente precisa para funcionar.

Este documento não exige nenhuma implementação específica de livro-razão distribuído. Exige uma propriedade de design: os participantes devem poder determinar a validade aplicando localmente a Especificação Inicial a um estado compartilhado ou replicável, sem pedir permissão ou status a uma autoridade permanente.

3. Convenções e definições

3.1. Linguagem de requisitos

Os termos de requisito em maiúsculas neste documento devem ser interpretados no sentido definido pela BCP 14, especificamente pelas RFC 2119 e RFC 8174.

3.2. Terminologia

Especificação Inicial:
O conjunto de regras, estruturas de dados, formatos, invariantes, procedimentos de validação, regras de transição de estado e regras de conflito necessários para a primeira implantação de um sistema.

Camada comum (Common Layer):
O conjunto mínimo de regras compartilhadas ou estrutura de referência necessário para que participantes independentes interoperem. A camada comum não é uma instituição. É a substância técnica que os participantes implementam e verificam.

Livro-razão distribuído (Distributed Ledger):
Um registro replicado ou de outra forma distribuído de transições de estado que permite aos participantes verificar a validade ordinária sem depender de um registro permanente, comitê ou outra autoridade. O termo não exige nenhum algoritmo de consenso ou implementação específica.

Regra de validação determinística (Deterministic Validation Rule):
Uma regra que permite a um participante decidir, por computação local ou verificação local, se um estado, registro, transição, afirmação ou mensagem é válido segundo um conjunto especificado de regras.

Invariante global (Global Invariant):
Uma propriedade que deve permanecer comum dentro de um conjunto de compatibilidade para preservar unicidade, interoperabilidade básica, integridade da prova de controle, segurança compartilhada ou segurança.

Participante (Participant):
Um operador, implementação, nó, rede, organização ou outro ator que executa, verifica, implanta ou depende do sistema.

Conjunto de compatibilidade (Compatibility Set):
Um grupo de participantes cujas regras de validação implementadas permitem que eles interoperem entre si. Uma mudança posterior pode criar um novo conjunto de compatibilidade se alguns participantes a adotarem e outros não.

Adoção (Adoption):
Implementação, implantação, validação e uso reais pelos participantes que executam o sistema.

Aceitação de contraparte (Counterparty Acceptance):
Decisão voluntária de um participante de aceitar, transacionar, interoperar ou confiar no estado de outro participante segundo as regras de validação que executa.

Não adoção (Non-Adoption):
Decisão de um participante de não implementar ou não usar uma mudança proposta. A não adoção não cria um estado de invalidez. Significa apenas que o participante não entrou no conjunto de compatibilidade criado por essa mudança.

Rejeição local (Local Rejection):
Decisão local de um participante de ignorar, rejeitar ou não interoperar com um estado, mensagem, registro ou transição que seja inválido ou incompatível segundo as regras de validação que ele executa.

Bifurcação (Fork):
Uma divergência nas regras de validação ou na prática operacional que cria dois ou mais conjuntos de compatibilidade.

Artefato de coordenação (Coordination Artifact):
Um documento, recomendação, nota de implementação, perfil, implementação de referência, explorador de livro-razão, réplica ou outro artefato que ajuda os participantes a se coordenarem. Um artefato de coordenação não cria uma realidade operacional vinculante a menos que os participantes o adotem em sistemas em execução.

4. Formulação do problema

Os designers costumam tentar reduzir a incerteza futura escrevendo demais na camada fundacional ou deixando a um organismo permanente a interpretação de questões futuras. Isso parece prudente. Muitas vezes é perigoso.

A superespecificação na camada fundacional tem três custos.

Primeiro, transfere decisões futuras para uma camada comum na qual a mudança é mais difícil e a captura tem maior efeito.

Segundo, cria ambiguidade entre validade técnica e reconhecimento institucional.

Terceiro, incentiva um organismo que mantém registros, publica documentos ou convoca participantes a tratar esses atos como autoridade sobre a realidade futura.

O mesmo problema aparece depois da implantação. Se um sistema exige um organismo permanente para aprovar mudanças, determinar estados ou interpretar a operação ordinária, o sistema criou uma camada de controle pós-fundação. Essa camada pode começar como administração. Pode se tornar governança. E pode se tornar um ponto de estrangulamento.

O objetivo de design deste documento não é uma discricionariedade institucional melhor. É evitar a necessidade dessa discricionariedade.

Um sistema de coordenação da Internet bem projetado deveria definir regras de validade determinísticas e verificáveis localmente desde o início; representar o estado válido de forma distribuída ou replicável; manter decisões que não sejam invariantes fora da camada comum; e permitir que mudanças posteriores se tornem reais apenas quando os participantes as adotarem voluntariamente em sistemas em execução.

5. Princípio 1: Especificação Inicial Mínima

5.1. Declaração

Uma Especificação Inicial DEVERIA definir apenas as regras comuns determinísticas mínimas necessárias para interoperabilidade básica, unicidade, prova de controle, segurança compartilhada e segurança.

5.2. Requisitos

Um design que utilize este princípio:

• DEVE identificar explicitamente seus Invariantes Globais.
• DEVE definir regras de validação determinísticas para cada Invariante Global.
• DEVE definir como o estado válido é representado, replicado, verificado e atualizado.
• NÃO DEVE incluir uma regra na Especificação Inicial a menos que ela seja necessária para preservar um Invariante Global declarado ou permitir a implantação inicial.
• DEVE separar regras de validação de preferências políticas, acordos comerciais, papéis institucionais, aspirações de governança e julgamento discricionário.
• DEVE permitir que os participantes verifiquem a validade ordinária localmente sem solicitar informações a qualquer instituição, registro, comitê, organismo de políticas ou outra autoridade.
• DEVERIA definir estruturas de dados, assinaturas, provas, regras de transição de estado, regras de conflito ou outros mecanismos necessários à verificação local.
• DEVERIA definir sinalização de extensões, versionamento, rotulagem de compatibilidade ou identificação de bifurcações quando a variação futura for previsível.
• DEVE garantir que os artefatos de coordenação necessários sejam portáteis, auditáveis, reproduzíveis e substituíveis.
• DEVERIA preferir condições objetivas verificáveis por máquina a julgamentos subjetivos de mérito.
• NÃO DEVE fazer do reconhecimento institucional futuro o único caminho pelo qual um estado válido possa ser conhecido, registrado ou utilizado.

5.3. Implicações de design

A Especificação Inicial Mínima não significa uma especificação vaga. Significa uma especificação rigorosa apenas do que precisa ser comum.

Um sistema ainda precisa de estrutura comum suficiente para funcionar. A disciplina consiste em distinguir entre:

• o que precisa ser comum para unicidade, interoperabilidade, prova de controle, segurança compartilhada e segurança; e
• o que pode permanecer fora da camada comum porque pertence à preferência do operador, prática comercial, escolha de contraparte, momento da implantação ou decisões posteriores de adoção.

Um design que não consiga expressar claramente seus Invariantes Globais e suas regras de validação determinísticas deveria presumir que especificou discricionariedade demais e pouca substância verificável.

6. Princípio 2: Decisão Futura Localizada

6.1. Declaração

Depois da Especificação Inicial, as Decisões Futuras DEVERIAM permanecer locais aos participantes que executam código. Uma Decisão Futura se torna efetiva apenas para o conjunto de compatibilidade cujos participantes a adotam. Nenhuma autoridade permanente é necessária para aprová-la, e a não adoção não cria um estado de invalidez.

6.2. Requisitos

Um design que utilize este princípio:

• NÃO DEVE exigir que os participantes obtenham permissão de uma instituição incumbente, registro, comitê, conselho, organismo de políticas ou outra autoridade para decisões que não alterem as regras de validação determinísticas do conjunto de compatibilidade ao qual pertencem.
• NÃO DEVE criar um organismo permanente cujo reconhecimento seja o único caminho para que uma mudança posterior se torne realidade operacional.
• DEVE distinguir entre validade sob a Especificação Inicial e compatibilidade com uma mudança opcional posterior.
• NÃO DEVE tratar a não adoção de uma mudança posterior como invalidez.
• DEVE permitir que os participantes permaneçam em um conjunto de compatibilidade existente quando não adotarem uma mudança posterior.
• DEVE permitir que os participantes entrem em um novo conjunto de compatibilidade por meio da adoção de novas regras de validação ou perfis operacionais.
• DEVE permitir que os participantes rejeitem localmente estados, registros, transições ou mensagens inválidos ou incompatíveis segundo as regras de validação que executam.
• DEVE permitir que os participantes escolham contrapartes voluntariamente segundo as regras de validação e os conjuntos de compatibilidade que aceitam.
• NÃO DEVE autorizar qualquer instituição, registro, comitê, organismo de políticas ou outro ator a declarar um participante inválido apenas porque ele rejeitou uma mudança posterior.
• DEVERIA tornar explícitos forks, versões, perfis ou conjuntos de compatibilidade para que os participantes saibam quais regras executam e com quais outros participantes podem interoperar.
• DEVERIA evitar qualquer design no qual um registro incumbente possa impedir que participantes que continuam válidos continuem interoperando.

6.3. Implicações de design

A Decisão Futura Localizada não significa que uma autoridade central atribua decisões futuras a atores locais. Significa que o sistema foi projetado de modo que, depois da Especificação Inicial, decisões futuras ordinárias não exijam essa atribuição.

A Especificação Inicial realiza antecipadamente o trabalho de limitação. Define os invariantes mínimos necessários para unicidade, interoperabilidade, prova de controle, segurança compartilhada e segurança. Todo o restante fica fora da camada comum.

A mudança futura não é aprovada centralmente. É adotada, ignorada, bifurcada ou abandonada pelos participantes que executam código.

Um participante que rejeita uma mudança pode permanecer fora do conjunto de compatibilidade criado por ela. Pode se desconectar de outros. Pode continuar em um conjunto de compatibilidade anterior. Pode bifurcar. Pode interoperar seletivamente. Mas não pode romper a interoperabilidade de outros participantes que continuam executando regras mutuamente compatíveis.

O efeito de um estado inválido ou incompatível é a rejeição local, não a punição. Não é necessário que alguém determine que um participante está em situação irregular. Um participante que executa regras de validação compatíveis simplesmente não aceita o estado inválido ou incompatível.

7. Princípio 3: Adoção Voluntária

7.1. Declaração

Mudanças em um sistema de coordenação da Internet DEVERIAM se tornar realidade operacional por meio de implementação, validação, implantação, aceitação por contrapartes e adoção pelos participantes, e não apenas por publicação ou declaração.

7.2. Requisitos

Um design que utilize este princípio:

• NÃO DEVE considerar publicação, recomendação, aprovação em reuniões ou aprovação processual suficientes para criar uma obrigação operacional universal.
• DEVE permitir que novas regras, extensões, perfis ou procedimentos sejam implantados incrementalmente pelos participantes que decidirem executá-los.
• DEVE permitir que os participantes rejeitem uma mudança posterior sem adquirir um estado de invalidez, desde que suas próprias transições de estado cumpram as regras determinísticas de seu conjunto de compatibilidade.
• DEVE permitir que os participantes continuem usando um conjunto de compatibilidade anterior quando a Especificação Inicial permitir essa continuidade.
• DEVE permitir que participantes que operam em um conjunto de compatibilidade rejeitem ou ignorem localmente estados de outro conjunto quando as regras forem incompatíveis.
• DEVERIA definir caminhos de adoção para mudanças importantes, incluindo sinalização de versões, rotulagem de compatibilidade, guias de transição e vetores de teste.
• DEVERIA definir caminhos de rejeição para mudanças importantes, incluindo como os participantes não adotantes continuam operando, identificam seu conjunto de compatibilidade e evitam interoperabilidade ambígua.
• DEVE garantir que os artefatos de coordenação necessários possam ser abandonados, replicados, reimplementados ou substituídos sem custos de transição impossíveis.
• DEVERIA fazer com que registros, recomendações e artefatos de coordenação descrevam a realidade adotada, em vez de tentar declarar existente uma realidade futura não adotada.
• NÃO DEVE projetar um sistema no qual a única forma de uma mudança se tornar real seja o reconhecimento prévio por um organismo incumbente.

7.3. Implicações de design

A Adoção Voluntária é o teste operacional para saber se uma mudança é útil, tolerável e compatível com a implantação real.

Uma proposta não é a realidade. Uma recomendação não é a realidade. Um documento não é a realidade. A realidade surge quando os participantes implementam, validam, implantam, aceitam contrapartes e dependem da mudança.

A não adoção não cria nenhum estado de infração. Cria apenas um fato: o participante não entrou no conjunto de compatibilidade criado pela mudança.

Isso não elimina processos de padronização, documentação, notas de implementação, exploradores, réplicas ou revisões. Limita seu alcance. Eles podem ajudar os participantes a se coordenar. Podem publicar material de referência. Podem descrever a adoção. Podem recomendar. Mas não podem, sozinhos e por declaração, tornar vinculante uma realidade futura não adotada para participantes que não a executam.

8. Relação entre os três princípios

Os três princípios se reforçam mutuamente e não são eficazes isoladamente.

A Especificação Inicial Mínima garante que a camada comum contenha regras de validação determinísticas, em vez de autoridade discricionária.

A Decisão Futura Localizada garante que decisões futuras permaneçam com os participantes que executam código, em vez de serem recapturadas por uma camada central de aprovação.

A Adoção Voluntária garante que mudanças posteriores tenham de sobreviver ao contato com implementação, verificação, aceitação por contrapartes e uso.

Um sistema que adote apenas um ou dois desses princípios pode reproduzir a mesma centralização por outros meios.

A Especificação Inicial Mínima sem Decisão Futura Localizada ainda pode permitir que a autoridade se acumule depois da implantação.
A Decisão Futura Localizada sem Especificação Inicial Mínima pode produzir ambiguidade, porque os participantes não conseguem determinar localmente a validade.
A Adoção Voluntária sem validação determinística pode produzir confusão, porque os participantes não conseguem distinguir variações compatíveis de estados inválidos.
A validação determinística sem estado distribuído ainda pode deixar os participantes dependentes de um registro privilegiado.
O estado distribuído sem visibilidade de bifurcações pode ocultar a discordância até a falha operacional.
O estado distribuído sem aceitação voluntária de contrapartes pode recriar coerção por meio de outra interface.

Juntos, os princípios produzem um sistema no qual a camada comum é estreita, a validade é verificável localmente, a mudança futura é voluntária, o estado é distribuído e nenhuma instituição permanente é necessária para decidir a operação ordinária.

9. Padrão de design recomendado

9.1. Camada comum distribuída determinística

A camada comum DEVERIA limitar-se a:

• semântica estável de identificadores;
• regras de validade determinísticas;
• regras de resolução de conflitos necessárias para preservar a unicidade;
• mecanismos de prova de controle;
• regras de transição de estado;
• requisitos de interoperabilidade em nível de rede ou protocolo;
• invariantes de segurança compartilhados;
• formatos de estado portáteis e auditáveis;
• visibilidade de estado distribuído ou replicado;
• sinalização de extensões e identificação de conjuntos de compatibilidade.

A camada comum NÃO DEVERIA conter:

• regras de modelos de negócio;
• regras de preços;
• preferências políticas regionais;
• ideologia de elegibilidade não relacionada a invariantes técnicos;
• poderes discricionários de execução;
• avaliações subjetivas de mérito;
• expansão da missão institucional;
• qualquer regra cuja função principal seja preservar a autoridade de um organismo incumbente.

9.2. Superfície de decisão do operador

O seguinte DEVERIA permanecer fora da camada comum, salvo se alterar diretamente um Invariante Global declarado:

• momento da implantação;
• uso comercial;
• geografia dos clientes;
• acordos de arrendamento, financiamento ou transferência;
• preferência local de elegibilidade;
• sequenciamento operacional;
• prática de roteamento não exigida para a validade compartilhada;
• modelo de negócio;
• estrutura organizacional;
• momento da migração voluntária;
• perfis ou extensões opcionais;
• escolha de contrapartes.

Os participantes PODEM adotar decisões diferentes nessas áreas. Essas decisões podem produzir conjuntos de compatibilidade diferentes, relações comerciais, acordos de peering ou comunidades operacionais. Não geram invalidez, salvo se violarem regras de validação determinísticas dentro de um conjunto de compatibilidade.

9.3. Ciclo de adoção

Quando possível, a ordem preferida para mudanças substanciais do sistema é:

• proposta;
• implementação;
• vetores de teste ou método de verificação determinística;
• implantação limitada por participantes que desejarem;
• observação dos efeitos de interoperabilidade e segurança;
• rotulagem dos conjuntos de compatibilidade;
• documentação ou recomendação que descreva a realidade adotada.

Um artefato de coordenação DEVERIA seguir a adoção, em vez de tentar antecipá-la.

9.4. Bifurcação, rejeição local e aceitação de contraparte

Um design em conformidade DEVERIA tratar bifurcação, rejeição local e aceitação de contrapartes como requisitos normais de design, e não como falhas.

O sistema DEVERIA definir como um participante pode:

• continuar em um conjunto de compatibilidade anterior;
• adotar um novo conjunto de compatibilidade;
• bifurcar para um conjunto de compatibilidade diferente;
• verificar o estado sem depender de um registro incumbente;
• aceitar contrapartes voluntariamente;
• rejeitar localmente estados inválidos ou incompatíveis;
• interoperar seletivamente quando a compatibilidade permitir.

Um sistema que não possa ser bifurcado ou verificado localmente sem destruir a operação válida, ou com o qual não se possa interoperar seletivamente sem destruir a operação válida, provavelmente ocultou poder de governança dentro de sua função registral.

10. Aplicabilidade e limites

Este padrão de design é particularmente aplicável quando:

• o sistema é multiator e multijurisdicional;
• a implantação independente é importante;
• a camada de coordenação deve permanecer estreita;
• é provável que exista variação futura, mas ela não possa ser prevista em detalhes;
• bloqueio ou dependência (lock-in) criariam risco de governança;
• a validade pode ser tornada determinística ou verificável localmente;
• o estado distribuído pode reduzir o risco de captura institucional.

Pode ser menos diretamente aplicável quando:

• um único domínio administrativo é a arquitetura prevista;
• um acoplamento forte em tempo real exige comportamento uniforme o tempo todo;
• considerações de segurança vital exigem uniformidade global imediata;
• a validade não pode ser verificada localmente por nenhum mecanismo prático.

Mesmo nesses casos, os designers DEVERIAM continuar minimizando a camada comum e evitar, tanto quanto possível, o controle discricionário futuro.

11. Não objetivos

Este documento não:

• proíbe toda coordenação;
• exige qualquer implementação específica de livro-razão distribuído;
• garante consenso;
• garante neutralidade política;
• exige que todos os participantes adotem cada mudança posterior;
• trata a recusa em adotar como invalidez;
• legitima comportamento local incompatível sob a alegação de compatibilidade;
• elimina a necessidade de regras comuns críticas para a segurança.

12. Considerações de segurança

Uma camada de coordenação mais estreita pode reduzir o risco de captura, diminuir o raio de impacto de erros institucionais e melhorar a capacidade de substituição. No entanto, maior discricionariedade local e estado distribuído também podem gerar posturas de segurança inconsistentes, caminhos de degradação, pressão de fragmentação, alegações ambíguas de compatibilidade, bifurcações inseguras, disputas sobre o estado do livro-razão e tentativas de falsificação de provas.

Portanto, os designers que aplicarem este documento DEVEM especificar explicitamente os invariantes de segurança. Em particular:

• os requisitos de autenticação e autorização necessários para a validade compartilhada DEVEM ser determinísticos e verificáveis localmente;
• os mecanismos de prova de controle DEVEM resistir a falsificação, repetição e transferência não autorizada;
• a negociação de versões e o tratamento de extensões DEVEM evitar degradações silenciosas quando a segurança for afetada;
• os caminhos de rejeição, bifurcação e substituição DEVEM ser analisados quanto ao risco de abuso e negação de serviço;
• as etiquetas de compatibilidade DEVERIAM ser claras o bastante para evitar interoperabilidade acidental entre conjuntos de regras incompatíveis;
• o estado distribuído DEVERIA ser auditável e reproduzível para detectar visões inconsistentes;
• a variação local NÃO DEVE poder declarar falsamente compatibilidade com um conjunto de regras que não cumpre.

A existência de exceções de segurança não justifica uma camada geral de permissões. Justifica apenas regras de segurança determinísticas necessárias para preservar os Invariantes Globais declarados.

13. Considerações da IANA

Este documento não requer ações da IANA.

14. Referências

14.1. Referências normativas

• RFC 2119 — Bradner, S., Palavras-chave para uso em RFCs para indicar níveis de requisito, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguidade entre maiúsculas e minúsculas nas palavras-chave da RFC 2119, BCP 14, RFC 8174.

14.2. Referências informativas

• RFC 6709 — Carpenter, B. e B. Aboba, Considerações de design para extensões de protocolo, RFC 6709.
• RFC 7282 — Resnick, P., Sobre consenso e zumbido na IETF, RFC 7282.

Apêndice A. Lista de verificação de design

Um design que afirme conformidade com este documento DEVERIA ser capaz de responder claramente às seguintes perguntas:

• Quais são os Invariantes Globais?
• Quais regras de validação determinísticas preservam esses Invariantes Globais?
• Quais regras da Especificação Inicial são estritamente necessárias para a primeira implantação?
• Como o estado válido é representado e verificado?
• O estado é distribuído, replicado ou de outra forma verificável independentemente?
• Quais questões futuras são intencionalmente deixadas fora da camada comum?
• Quais decisões futuras os participantes podem tomar sem alterar o conjunto de compatibilidade no qual estão?
• Como um participante adota uma mudança posterior?
• Como um participante rejeita uma mudança posterior sem receber um estado de invalidez?
• Como os conjuntos de compatibilidade são rotulados ou descobertos?
• Como funciona a rejeição local quando um estado é inválido ou incompatível segundo as regras executadas por um participante?
• Qual é o caminho da bifurcação?
• Como um titular demonstra controle sem um registro incumbente?
• Como uma contraparte verifica o estado sem um registro?
• Os participantes podem verificar a validade ordinária sem depender de um registro incumbente?
• Os registros e artefatos de coordenação descrevem a realidade adotada ou tentam declarar existente uma realidade futura não adotada?
• O sistema minimizou o número de decisões incorporadas à camada comum?
• O sistema evitou qualquer autoridade permanente que determine o estado ordinário dos participantes?
• Os participantes podem aceitar ou rejeitar contrapartes voluntariamente?
• O sistema pode continuar se todos os registros incumbentes desaparecerem?

Endereço do autor

Lu
[TBD]