RIO_X

Meus olhos estão cansados e meu cérebro está dormente depois de assistir ao gráfico de PAXG e XAG. então eu deixei isso
só notei algo enquanto revisava a seção de poeira esta manhã e, honestamente, isso reformula como o midnight lida com um dos problemas mais persistentes no blockchain 😂
MEV - valor máximo extraível - é a prática de validadores ou atores sofisticados de reordenar, inserir ou censurar transações para extrair lucro. isso existe porque na maioria das cadeias, transações pendentes são visíveis antes de serem liquidadas. se você pode ver o que alguém está prestes a fazer, você pode antecipar.
o recurso de poeira do midnight corta essa superfície de ataque na fonte.

o que isso acerta:
a poeira é protegida. quando uma transação é submetida, a poeira sendo gasta não é visível para contrapartes ou disponível no livro público. endereços de carteira, valores de transação e timestamps não são divulgados. não há trilha de metadados para correlacionar. um validador olhando para o mempool não pode identificar possíveis vítimas porque as informações necessárias para direcioná-las simplesmente não estão lá.
e a poeira queima ao ser usada. não pode ser acumulada, transferida ou mantida como uma reserva de valor. um atacante não pode construir uma posição de poeira para usar como alavancagem da maneira que poderia acumular uma posição de token em uma cadeia transparente. o recurso desaparece ao ser consumido.
a combinação - protegido na submissão, queimado ao usar - remove tanto a visibilidade quanto o ângulo de acumulação do qual o MEV geralmente depende.

o que continua me incomodando:
a resistência ao MEV é descrita como uma propriedade do design da poeira. mas o MEV sofisticado no midnight provavelmente miraria na camada noturna não protegida, não em transações de poeira diretamente. esse ângulo não é abordado.
honestamente, não sei se a proteção e queima da poeira tornam o midnight genuinamente resistente ao MEV na camada de transação ou apenas movem a superfície de ataque para a camada não protegida onde a noite se move à vista do público?? 🤔
#night @MidnightNetwork $NIGHT

Depois de terminar de negociar no PIPPIN e RIVER na noite passada
voltei a revisar a documentação da fundação SIGN esta manhã e honestamente um conjunto de números tem estado comigo desde que os li pela primeira vez 😂
na Serra Leoa, 73% dos cidadãos têm um número de identidade nacional. apenas 5% possuem um cartão de identidade real. essa diferença de 68 pontos não é um problema de dados. é um problema de acesso. a identidade existe em um registro governamental em algum lugar. o cidadão simplesmente não pode prová-la a ninguém

e essa lacuna causa diretamente 66% de exclusão financeira, não porque a infraestrutura financeira não exista.

porque a camada de identidade que fica por baixo não tem um mecanismo de entrega de última milha

você não pode abrir uma conta bancária com um número que ninguém pode verificar
você não pode receber um pagamento digital em uma carteira vinculada a uma identidade que você não pode apresentar.
este é exatamente o problema que a arquitetura de credenciais verificáveis da SIGN foi projetada para resolver
uma credencial em um telefone, verificável offline via QR, nenhum cartão necessário. a lacuna de infraestrutura que criou aquele número de 66% de exclusão é um problema de apresentação tanto quanto um problema de emissão.

honestamente, não sei se as credenciais verificáveis com foco em celular realmente alcançam as populações mais excluídas ou se o problema da última milha simplesmente se move da distribuição de cartões para o acesso a smartphones?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN

passei a manhã de hoje revisando os parâmetros de produção de blocos e, honestamente, essa linha me parou em seco 😂
A maioria das pessoas assume que o número de validadores que produzem blocos em uma rede determinada é fixado pelo protocolo ou cresce naturalmente com a participação. À meia-noite, o tamanho do comitê, o número de produtores de blocos selecionados a cada época, é um parâmetro de sistema configurável.
a governança controla isso.

O que isso acerta:
a flexibilidade é genuinamente útil aqui. Uma rede em estágios iniciais precisa de um comitê mais restrito e gerenciável. À medida que a participação cresce e a descentralização se aprofunda, expandir o tamanho do comitê é o movimento certo. Tê-lo como um parâmetro em vez de uma constante codificada significa que a rede pode se adaptar sem um hard fork.

O que continua me incomodando:
ao ser lançado, esse parâmetro está dentro da governança federada. Um comitê cujos membros ainda não foram identificados controla quantos produtores de blocos são selecionados a cada época. Isso é uma alavanca significativa. Um comitê menor significa uma produção de blocos mais concentrada. Um maior significa mais distribuída. O número não é neutro, e as pessoas que o definem ainda não foram nomeadas.
honestamente, não sei se um tamanho de comitê configurável é o design certo que permite à meia-noite escalar a produção de blocos de maneira sensata à medida que a rede amadurece ou um parâmetro que concentra uma decisão crítica da rede nas mãos de uma estrutura de governança indefinida no exato momento em que isso mais importa?? Parece semelhante à rede SOLANA, eu acho?🤔
#night @MidnightNetwork $NIGHT

estou passando por algumas negociações de BITCOIN e ETHEREUM e as mecânicas de distribuição do Midnight TokenTable desde a noite passada e, honestamente, a reivindicação de prevenção de duplicatas é a parte que continuo refletindo

o design é limpo na superfície. os benefícios são distribuídos para atestações de identidade verificadas. cada identidade é única na blockchain. a mesma identidade não pode reivindicar duas vezes. o protocolo impõe isso no nível do contrato.

mas aqui está o que não consigo superar.

a prevenção de duplicatas na camada de distribuição assume a deduplicação de identidade limpa na camada de identidade subjacente. uma pessoa real equivale a uma identidade verificada. em um sistema maduro sem dados legados, isso se mantém. em uma implantação soberana real, isso nem sempre se mantém. bancos de dados de IDs governamentais em países em desenvolvimento frequentemente possuem registros duplicados. duas inscrições para a mesma pessoa com grafias de nomes ligeiramente diferentes, dois números de identificação nacional emitidos para o mesmo indivíduo em diferentes períodos administrativos. ambos são verificados. ambos se tornam identidades válidas na blockchain. ambos reivindicam o benefício.

o protocolo impediu que uma identidade reivindicasse duas vezes. ele não tinha como saber que duas identidades eram a mesma pessoa.
honestamente, não sei se a prevenção de duplicatas vinculada à identidade é forte o suficiente para a distribuição de benefícios soberanos ou se apenas move o problema de deduplicação uma camada para baixo, onde o protocolo não consegue ver isso?? 🤔

#SignDigitalSovereignInfra @SignOfficial $SIGN

apenas reli as especificações da cadeia soberana L2 esta manhã e, honestamente, a seção do sequenciador é a parte com a qual não consigo parar de pensar 😂

o governo controla o sequenciador. esse é o design. ele ordena e agrupa cada transação de cidadão que flui através da cadeia de pagamento nacional. isenções de gás, controle do conjunto de validadores, ordenação de transações - tudo isso passa por esse único componente que a autoridade soberana opera. e em dias normais isso faz total sentido. você quer que uma ferrovia de pagamento nacional seja governável. você não quer que validadores aleatórios decidam o que é processado primeiro em uma infraestrutura que lida com pagamentos de assistência social e transferências de títulos de terra.
mas eu fui procurar o que acontece quando o sequenciador fica offline.
o whitepaper diz que os usuários podem sair para L1 se o L2 enfrentar problemas. essa é toda a descrição do fallback. quem aciona essa saída não é especificado. como é a janela de recuperação não é especificado. se um sequenciador de fallback existe não é especificado.

para um protocolo DeFi privado, isso é um trade-off conhecido. para uma infraestrutura soberana que atende milhões de cidadãos - o tempo de inatividade do sequenciador significa que a cadeia de pagamento nacional para.
honestamente, não sei como as coisas estão indo com preços como SOLANA e RIVER também, então se a arquitetura de sequenciador único é um design aceitável para um governo que entende e aceita esse trade-off ou uma lacuna crítica que precisa de um failover definido antes que qualquer nação realmente entre em operação?? 🤔

#SignDigitalSovereignInfra @SignOfficial $SIGN

estive pensando sobre isso desde a noite passada e honestamente, quanto mais eu reflito sobre isso, mais muda a maneira como leio toda a arquitetura de privacidade 😂
A maioria das pessoas assume que uma blockchain armazena tudo. Esse é o objetivo de um livro-razão distribuído - seus dados estão em algum lugar na rede, replicados entre nós, recuperáveis. A midnight muda completamente essa suposição.
Os dados privados na midnight vivem na sua máquina. Não na rede
Não replicados entre nós
Seu dispositivo local
A rede armazena apenas as provas ZK que atestam a correção dos seus dados privados - não os dados em si. O que vai para a blockchain é a prova de que algo aconteceu, não o que aconteceu.
O que isso acerta: a garantia de privacidade é genuína. Ninguém pode extrair seus dados privados da rede porque a rede simplesmente não os tem. Violações de dados no nível da rede não podem expor o que nunca foi armazenado lá.
O que me incomoda:
Se o seu estado local for perdido - dispositivo corrompido, carteira perdida, backup falhado - a rede não tem um caminho de recuperação para você. As provas existem na blockchain para sempre. Os dados que as geraram se foram. Você não pode reconstruir seu estado privado a partir do que a rede possui porque a rede deliberadamente retém menos do que o quadro completo.
Isso não é um defeito de design. É uma troca intencional. A soberania dos dados significa que você possui seus dados completamente - incluindo o risco de perdê-los.
Honestamente, não sei se o armazenamento local de estado privado é a arquitetura correta para a verdadeira posse de dados ou um design que transferiu silenciosamente todo o fardo da recuperação de dados para usuários individuais de uma maneira que a maioria não apreciará totalmente até que algo dê errado, como o que aconteceu com a RIVER ?? 🤔

#night @MidnightNetwork $NIGHT

fiquei acordado noite passada revisando as especificações técnicas do rCBDC e, honestamente, algo sobre a afirmação da capacidade offline não me deixa em paz 😂

o CBDC de varejo funciona em um modelo UTXO. transações consomem saídas não gastas e criam novas. a rede rastreia quais saídas foram gastas. a prevenção de gasto duplo funciona porque a rede vê cada transação antes que a saída seja marcada como consumida.
a capacidade offline quebra essa suposição
se um cidadão em uma área de baixa conectividade transaciona offline, essa transação chega à rede mais tarde. mas entre o momento em que a transação offline acontece e o momento em que é finalizada - a mesma saída não gasta ainda parece válida para qualquer outra pessoa com quem esse cidadão interage offline

o documento lista o suporte offline como uma característica de inclusão financeira. eles não descrevem o mecanismo que impede a mesma UTXO de ser gasta duas vezes antes que qualquer transação chegue à rede

honestamente, não sei se as transações CBDC offline têm uma solução criptográfica para isso que simplesmente não está documentada neste nível ou se a janela de gasto duplo é um trade-off conhecido que o design aceita em troca de acesso de baixa conectividade?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN

acabei de notar algo na seção de congestionamento esta manhã e, honestamente, isso muda a forma como você pensa sobre resistência a spam à meia-noite 😂
a maioria dos mecanismos anti-spam depende do custo da taxa. faça com que cada transação seja cara o suficiente para que sustentar milhões delas drene o atacante mais rapidamente do que drena a rede. a meia-noite tem isso com DUST. mas há uma segunda camada de custo que não é discutida.
toda transação blindada na meia-noite requer uma prova ZK. quando o DUST é consumido em uma transação, uma prova é necessária para justificar a propriedade do DUST sendo gasto. gerar essa prova é computacionalmente intensivo
verificá-la não é
a assimetria é significativa e intencional.
o whitepaper a descreve precisamente.
gerar uma prova ZK é muito mais caro do que verificá-la. isso cria um custo auto-infligido para qualquer atacante tentando inundar a rede com transações. cada tentativa de spam requer que o atacante gere uma nova prova. a rede só precisa verificá-la - uma fração do trabalho.
e se as taxas aumentarem devido ao congestionamento, transações sem DUST suficiente são rejeitadas e requerem nova submissão. nova submissão significa gerar uma nova prova. outro custo computacional total para o atacante, outra verificação barata do lado da rede.
atores racionais veem o custo e param. os irracionais eventualmente esgotam seu DUST.
honestamente, não sei se a assimetria da prova ZK é o mecanismo elegante de autodefesa que torna a meia-noite genuinamente resistente a spam sustentado ou apenas um obstáculo que um atacante bem equipado com hardware suficiente considera um pequeno inconveniente?? 🤔
#night @MidnightNetwork $NIGHT #creatorpad

acabei de passar esta manhã analisando a camada de consenso e, honestamente, a separação aqui me pegou de surpresa, assim como o gráfico da moeda LYN 😂
a maioria das pessoas assume que a produção de blocos e a finalização de blocos são o mesmo evento
um validador produz um bloco
a rede o aceita
done
é assim que se sente do lado de fora.
a meia-noite executa dois mecanismos completamente separados para essas duas tarefas.
AURA lida com a produção. atribuição de slots em round-robin, intervalos fixos, cada validador faz sua vez. cobrimos isso. mas a AURA apenas decide quem produz o próximo bloco e quando. não diz nada sobre se esse bloco é permanente.
GRANDPA lida com a finalização. Acordo de Prefixo Derivando Ancestor Recursivo Baseado em GHOST. funciona ao lado da AURA e determina quais blocos são realmente irreversíveis. não apenas adicionados à cadeia - estabelecidos permanentemente, não podem ser reorganizados.

a distinção importa mais do que parece. um bloco pode existir na cadeia sem ser finalizado

GRANDPA funciona fazendo com que os validadores votem em cadeias em vez de blocos individuais - ele encontra o bloco mais alto para o qual dois terços dos validadores votaram como ancestrais e finaliza tudo até aquele ponto em uma operação. isso significa que a finalização pode ser feita em múltiplos blocos de uma vez, em vez de confirmar um de cada vez
o que isso acerta é a separação de preocupações. a velocidade de produção e as garantias de finalização são problemas diferentes com diferentes compensações. mantê-los separados permite que cada mecanismo otimize seu próprio trabalho.
mas aqui está a questão. a finalização depende da participação dos validadores na votação do GRANDPA. no lançamento, com um pequeno conjunto de validadores autorizados, essa participação é controlável. à medida que o conjunto se expande para incluir SPOs do Cardano, as suposições de finalização mudam.
honestamente, não sei se separar a produção da finalização é o design limpo em duas camadas que dá à meia-noite tanto velocidade quanto garantias de liquidação ou uma dependência que se torna mais complexa para raciocinar à medida que o conjunto de validadores cresce?? 🤔
#night @MidnightNetwork $NIGHT

acabei de passar a manhã revisando os documentos de arquitetura do S.I.G.N. e honestamente algo sobre o modelo de colocação de dados não para de me incomodar 😀

o design é realmente reflexivo. passaportes, biometria, arquivos de programas sensíveis - nada disso vai na cadeia. o que vai na cadeia é apenas o hash. um âncora criptográfica. a carga off-chain permanece criptografada, a referência on-chain permanece verificável

separação limpa no papel.

mas aqui está o que não consigo parar de pensar.

o padrão híbrido está listado como "recomendado." o que significa que o modelo apenas hash é opcional. uma implementação poderia colocar mais na cadeia do que o pretendido, ou manter tanto fora da cadeia que a âncora on-chain se torna não verificável na prática se o armazenamento off-chain falhar. a garantia de integridade só se mantém se alguém estiver verificando ativamente se a carga off-chain ainda corresponde ao hash on-chain. os olhos estão doendo agora ao ler o whitepaper e assistir ao gráfico de LYN e RIVER
honestamente não sei se o modelo de colocação híbrida é a arquitetura elegante de preservação de privacidade que parece ser ou um design que depende inteiramente da disciplina operacional que o próprio protocolo não consegue impor?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN