Binance Square
BarBie_QueeN
195 Publicações

BarBie_QueeN

Aberto ao trading
Trader Frequente
3.3 mês(es)
11 A seguir
91 Seguidores
1.2K+ Gostaram
Publicações
Portfólio
PINNED
·
--
@Dusk_Foundation Eu costumava achar que provar quem você é e provar que você tem permissão para fazer algo eram basicamente o mesmo problema. Aí cheguei à seção do Citadel no whitepaper de Dusk, e essa suposição não se sustentou. Aqui está o mecanismo real: um contrato de licença verifica se você está portando uma credencial válida e não revogada antes de permitir que você execute uma ação específica. Ele não pergunta quem você é por baixo dessa credencial. Pense num segurança verificando um documento num bar. Ele não precisa do seu endereço residencial nem do seu nome civil completo. Ele precisa de um fato: você tem mais de 21 anos. A maioria dos sistemas digitais não consegue fazer essa distinção — você acaba fornecendo toda a sua identidade só para confirmar uma coisinha sobre você. O Citadel foi construído para não fazer isso. Essa é a parte que parece menos um teatro de cripto e mais uma infraestrutura legal de verdade. Licenciamento, permissões, revogações — reguladores já pensam assim. O Citadel apenas desloca a aplicação de um cartório de registros para o código. Mas o código, porém, só consegue confirmar o que lhe é dito. Ele pode verificar que uma licença não foi revogada. Ele não pode decidir o que deveria contar como um motivo válido para revogar uma, nem resolver uma briga entre um regulador e um protocolo que discordam sobre o mesmo fato. Tribunais fazem esse trabalho. Contratos não. Então ainda não sei o quanto disso sobrevive ao contato com um sistema jurídico real — e eu não acho que seja um lugar ruim para estar. Ler o papel real do Citadel antes de presumir que qualquer coisa está resolvida parece ser a intuição certa aqui. Continuar um pouco incerto e, ainda assim, perguntar provavelmente é só um bom hábito em geral. Não só para isso. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
@Dusk
Eu costumava achar que provar quem você é e provar que você tem permissão para fazer algo eram basicamente o mesmo problema. Aí cheguei à seção do Citadel no whitepaper de Dusk, e essa suposição não se sustentou.
Aqui está o mecanismo real: um contrato de licença verifica se você está portando uma credencial válida e não revogada antes de permitir que você execute uma ação específica. Ele não pergunta quem você é por baixo dessa credencial.
Pense num segurança verificando um documento num bar. Ele não precisa do seu endereço residencial nem do seu nome civil completo. Ele precisa de um fato: você tem mais de 21 anos. A maioria dos sistemas digitais não consegue fazer essa distinção — você acaba fornecendo toda a sua identidade só para confirmar uma coisinha sobre você. O Citadel foi construído para não fazer isso.
Essa é a parte que parece menos um teatro de cripto e mais uma infraestrutura legal de verdade. Licenciamento, permissões, revogações — reguladores já pensam assim. O Citadel apenas desloca a aplicação de um cartório de registros para o código.
Mas o código, porém, só consegue confirmar o que lhe é dito. Ele pode verificar que uma licença não foi revogada. Ele não pode decidir o que deveria contar como um motivo válido para revogar uma, nem resolver uma briga entre um regulador e um protocolo que discordam sobre o mesmo fato. Tribunais fazem esse trabalho. Contratos não.
Então ainda não sei o quanto disso sobrevive ao contato com um sistema jurídico real — e eu não acho que seja um lugar ruim para estar. Ler o papel real do Citadel antes de presumir que qualquer coisa está resolvida parece ser a intuição certa aqui.
Continuar um pouco incerto e, ainda assim, perguntar provavelmente é só um bom hábito em geral. Não só para isso.
@Dusk #dusk $DUSK
@Dusk_Foundation Eu estava lendo o whitepaper da Dusk e voltava repetidamente a um pequeno trecho, escondido perto do fim: o contrato de licença, construído sobre o que eles chamam de protocolo Citadel. Não o mecanismo de consenso, não a tecnologia de privacidade. Apenas licenças. Mas talvez seja a parte que realmente importa. Foi isso que me chamou atenção. Na maioria das cadeias, possuir a chave privada é toda a história — você a tem, pode transacionar. A Dusk questiona isso para ativos regulados. O contrato de licença não apenas verifica uma assinatura; ele verifica se o detentor é até elegível para agir, e essa elegibilidade tem estado real: validade, expiração, renovação, revogação. Não é que licenças simplesmente vivam em uma blockchain — é que a própria elegibilidade se torna algo que a cadeia consegue executar, não apenas registrar. É isso que faz parecer menos um discurso e mais um design pensado para a lei de valores mobiliários na prática. A maior parte do DeFi começa com "qualquer carteira pode interagir". Isso começa com uma pergunta diferente — e se a própria elegibilidade for programável? Permitida especificamente onde a regulamentação exige, e não em todo o resto. Onde eu permaneço cauteloso é na aplicação. O código consegue controlar uma data de expiração. Mas não consegue decidir se um regulador de um país reconhece uma licença emitida no arcabouço de outro, nem o que acontece quando a lei e a execução discordam silenciosamente. Tokenizar um título nunca foi a parte difícil — fazer a conformidade viver dentro da camada de execução, e não como papelada parada por aí na cadeia, é. Nada disso significa que já esteja resolvido — apenas que vale a pena entender por conta própria, nos seus termos, sem engolir o discurso literalmente. Talvez este seja o verdadeiro hábito: continuar curioso, questionar o que chamam de "resolvido" e deixar seu entendimento crescer, projeto por projeto. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
@Dusk
Eu estava lendo o whitepaper da Dusk e voltava repetidamente a um pequeno trecho, escondido perto do fim: o contrato de licença, construído sobre o que eles chamam de protocolo Citadel. Não o mecanismo de consenso, não a tecnologia de privacidade. Apenas licenças. Mas talvez seja a parte que realmente importa.
Foi isso que me chamou atenção. Na maioria das cadeias, possuir a chave privada é toda a história — você a tem, pode transacionar. A Dusk questiona isso para ativos regulados. O contrato de licença não apenas verifica uma assinatura; ele verifica se o detentor é até elegível para agir, e essa elegibilidade tem estado real: validade, expiração, renovação, revogação. Não é que licenças simplesmente vivam em uma blockchain — é que a própria elegibilidade se torna algo que a cadeia consegue executar, não apenas registrar.
É isso que faz parecer menos um discurso e mais um design pensado para a lei de valores mobiliários na prática. A maior parte do DeFi começa com "qualquer carteira pode interagir". Isso começa com uma pergunta diferente — e se a própria elegibilidade for programável? Permitida especificamente onde a regulamentação exige, e não em todo o resto.
Onde eu permaneço cauteloso é na aplicação. O código consegue controlar uma data de expiração. Mas não consegue decidir se um regulador de um país reconhece uma licença emitida no arcabouço de outro, nem o que acontece quando a lei e a execução discordam silenciosamente. Tokenizar um título nunca foi a parte difícil — fazer a conformidade viver dentro da camada de execução, e não como papelada parada por aí na cadeia, é.
Nada disso significa que já esteja resolvido — apenas que vale a pena entender por conta própria, nos seus termos, sem engolir o discurso literalmente. Talvez este seja o verdadeiro hábito: continuar curioso, questionar o que chamam de "resolvido" e deixar seu entendimento crescer, projeto por projeto.
@Dusk #dusk $DUSK
Verificado
@Dusk_Foundation Esta semana estive lendo o whitepaper da Dusk e fiquei preso em um detalhe que quase passei: um "contrato de licença", construído sobre algo chamado Citadel, que verifica se você atende a uma condição em vez de verificar quem você é. Eu não tinha pensado em conformidade desse jeito antes — provar que você se qualifica em vez de entregar um ID. O que torna isso menos com cara de experimento mental é que a Dusk não está apenas teorizando. A rede já está ligada à NPEX, uma bolsa licenciada na Holanda operando sob obrigações reais de MiFID II e MiCA, com centenas de milhões em valores mobiliários tokenizados passando por ela. A Citadel é apresentada como a camada real de KYC para esse arranjo, não como uma demonstração lateral. Essa estrutura legal existente é o que faz tudo parecer mais real para mim do que a maioria das propostas de "futuro da conformidade". Ainda assim, continuo voltando à mesma dúvida. Uma prova de conhecimento zero pode confirmar que uma credencial é válida, mas não consegue decidir, por si só, quem é suficientemente confiável para emitir essa credencial em primeiro lugar. Os reguladores ainda precisam aceitar essa prova como evidência real, entre instituições, entre países, durante uma auditoria ou disputa de verdade — e isso é um processo mais lento e confuso do que escrever boa criptografia. A distância entre "isso pode funcionar tecnicamente" e "um regulador vai confiar nisso" é exatamente onde ideias como essa tendem a travar silenciosamente. Então estou tratando isso como algo interessante, não como algo resolvido. Vale a pena entender de perto, mas não vale assumir que já funciona do jeito que a apresentação sugere. Um lembrete pequeno para mim mesmo, e talvez para você também: continue lendo além da manchete. Sempre há mais para aprender, e as seções do meio, por mais chatas que sejam, geralmente são as que mais ensinam. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
@Dusk
Esta semana estive lendo o whitepaper da Dusk e fiquei preso em um detalhe que quase passei: um "contrato de licença", construído sobre algo chamado Citadel, que verifica se você atende a uma condição em vez de verificar quem você é. Eu não tinha pensado em conformidade desse jeito antes — provar que você se qualifica em vez de entregar um ID.

O que torna isso menos com cara de experimento mental é que a Dusk não está apenas teorizando. A rede já está ligada à NPEX, uma bolsa licenciada na Holanda operando sob obrigações reais de MiFID II e MiCA, com centenas de milhões em valores mobiliários tokenizados passando por ela. A Citadel é apresentada como a camada real de KYC para esse arranjo, não como uma demonstração lateral. Essa estrutura legal existente é o que faz tudo parecer mais real para mim do que a maioria das propostas de "futuro da conformidade".

Ainda assim, continuo voltando à mesma dúvida. Uma prova de conhecimento zero pode confirmar que uma credencial é válida, mas não consegue decidir, por si só, quem é suficientemente confiável para emitir essa credencial em primeiro lugar. Os reguladores ainda precisam aceitar essa prova como evidência real, entre instituições, entre países, durante uma auditoria ou disputa de verdade — e isso é um processo mais lento e confuso do que escrever boa criptografia. A distância entre "isso pode funcionar tecnicamente" e "um regulador vai confiar nisso" é exatamente onde ideias como essa tendem a travar silenciosamente.

Então estou tratando isso como algo interessante, não como algo resolvido. Vale a pena entender de perto, mas não vale assumir que já funciona do jeito que a apresentação sugere.

Um lembrete pequeno para mim mesmo, e talvez para você também: continue lendo além da manchete. Sempre há mais para aprender, e as seções do meio, por mais chatas que sejam, geralmente são as que mais ensinam.
@Dusk #dusk $DUSK
@Dusk_Foundation Eu estava lendo um artigo sobre blockchain na noite passada e fiquei preso em uma linha: o que acontece quando as pessoas que estão operando uma rede simplesmente ficam em silêncio? Não foi hackeado, não foi atacado, apenas ficou offline ou distraído. É uma pergunta pouco glamourosa, mas é ela que decide se um sistema está pronto para produção ou se é só uma demonstração. A Dusk, um projeto feito para finanças reguladas, responde com uma cascata em vez de uma correção única. Rodadas normais tentam chegar a um acordo sobre um bloco. Se muitas delas falharem em sequência, a rede não congela — ela muda para um modo em que os timeouts são desativados e as tentativas continuam rodando até que uma funcione. Múltiplas tentativas podem ocorrer ao mesmo tempo, então versões concorrentes do mesmo bloco podem existir brevemente lado a lado. O critério de desempate é quase banal: vence a versão que precisou de menos tentativas para chegar lá. E, se nada cair, existe um último recurso — um bloco vazio, produzido para manter a cadeia avançando. O que torna isso menos com cara de teoria é para quem foi construído: instituições que esperam que a infraestrutura financeira nunca apague. Essa é uma expectativa do mundo real antes mesmo de ser uma questão técnica. Mesmo assim, eu continuo voltando a uma dúvida. Um bloco vazio de “manter vivo” não é a mesma coisa que o sistema voltar a funcionar. E quando um fork é resolvido automaticamente, essa resolução tem o mesmo peso que um registro legal teria, se a propriedade estivesse em jogo? Código determinando o que é final e a lei determinando o que é final nem sempre estão dizendo a mesma coisa. Vale a pena ficar com isso, não apenas aceitar. Um sistema que nunca para não é automaticamente um sistema que nunca quebra. Aprendizado pequeno e constante — é isso que faz o efeito composto. #dusk @Dusk_Foundation $DUSK {spot}(DUSKUSDT)
@Dusk
Eu estava lendo um artigo sobre blockchain na noite passada e fiquei preso em uma linha: o que acontece quando as pessoas que estão operando uma rede simplesmente ficam em silêncio? Não foi hackeado, não foi atacado, apenas ficou offline ou distraído. É uma pergunta pouco glamourosa, mas é ela que decide se um sistema está pronto para produção ou se é só uma demonstração.

A Dusk, um projeto feito para finanças reguladas, responde com uma cascata em vez de uma correção única. Rodadas normais tentam chegar a um acordo sobre um bloco. Se muitas delas falharem em sequência, a rede não congela — ela muda para um modo em que os timeouts são desativados e as tentativas continuam rodando até que uma funcione. Múltiplas tentativas podem ocorrer ao mesmo tempo, então versões concorrentes do mesmo bloco podem existir brevemente lado a lado. O critério de desempate é quase banal: vence a versão que precisou de menos tentativas para chegar lá. E, se nada cair, existe um último recurso — um bloco vazio, produzido para manter a cadeia avançando.

O que torna isso menos com cara de teoria é para quem foi construído: instituições que esperam que a infraestrutura financeira nunca apague. Essa é uma expectativa do mundo real antes mesmo de ser uma questão técnica.

Mesmo assim, eu continuo voltando a uma dúvida. Um bloco vazio de “manter vivo” não é a mesma coisa que o sistema voltar a funcionar. E quando um fork é resolvido automaticamente, essa resolução tem o mesmo peso que um registro legal teria, se a propriedade estivesse em jogo? Código determinando o que é final e a lei determinando o que é final nem sempre estão dizendo a mesma coisa.

Vale a pena ficar com isso, não apenas aceitar. Um sistema que nunca para não é automaticamente um sistema que nunca quebra.

Aprendizado pequeno e constante — é isso que faz o efeito composto.
#dusk @Dusk $DUSK
Eu estava lendo recentemente alguma documentação sobre blockchain e fiquei preso em uma pequena ideia: e se provar algo não significasse revelar tudo? A maioria de nós pensa em privacidade em termos binários — ou seus dados são públicos, ou ficam trancados. Mas existe um meio-termo do qual eu não tinha pensado muito antes: divulgação seletiva. O design da rede Dusk toca nisso em alguns pontos. O modelo de transações Phoenix usa chaves de visualização que permitem que uma parte confiável confirme que uma transação aconteceu, sem nunca entregar a capacidade de gastar os fundos. Também há um sistema de licenciamento ligado a um protocolo de identidade autocustodiada (self-sovereign), no qual ter uma licença válida deve servir para provar que você está autorizado a fazer algo, sem precisar entregar toda a sua identidade apenas para provar isso. Essa distinção parece importante. Ela reflete como a conformidade realmente funciona na vida real — um proprietário não precisa do seu extrato bancário completo; ele só precisa de uma prova de que você pode pagar o aluguel. Um segurança precisa da sua idade, não do seu endereço. Quando um sistema é construído para revelar apenas exatamente o que é necessário, ele começa a parecer menos um experimento cripto e mais uma infraestrutura real. Mas eu também continuo um pouco cético aqui. A criptografia pode provar que um fato é verdadeiro — ela não consegue decidir quem deve emitir esse fato, nem o que acontece quando uma credencial precisa ser revogada ou contestada. Tribunais, reguladores e instituições ainda precisam concordar que essas provas têm algum significado legal. Essa lacuna entre “a matemática funciona” e “a lei reconhece isso” ainda é grande na maior parte dos lugares. Então eu não estou totalmente convencido, só curioso. Vale a pena se aprofundar nos documentos reais do protocolo antes de confiar no discurso. Continuo aprendendo, continuo questionando — um whitepaper de cada vez. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Eu estava lendo recentemente alguma documentação sobre blockchain e fiquei preso em uma pequena ideia: e se provar algo não significasse revelar tudo? A maioria de nós pensa em privacidade em termos binários — ou seus dados são públicos, ou ficam trancados. Mas existe um meio-termo do qual eu não tinha pensado muito antes: divulgação seletiva.
O design da rede Dusk toca nisso em alguns pontos. O modelo de transações Phoenix usa chaves de visualização que permitem que uma parte confiável confirme que uma transação aconteceu, sem nunca entregar a capacidade de gastar os fundos. Também há um sistema de licenciamento ligado a um protocolo de identidade autocustodiada (self-sovereign), no qual ter uma licença válida deve servir para provar que você está autorizado a fazer algo, sem precisar entregar toda a sua identidade apenas para provar isso.
Essa distinção parece importante. Ela reflete como a conformidade realmente funciona na vida real — um proprietário não precisa do seu extrato bancário completo; ele só precisa de uma prova de que você pode pagar o aluguel. Um segurança precisa da sua idade, não do seu endereço. Quando um sistema é construído para revelar apenas exatamente o que é necessário, ele começa a parecer menos um experimento cripto e mais uma infraestrutura real.
Mas eu também continuo um pouco cético aqui. A criptografia pode provar que um fato é verdadeiro — ela não consegue decidir quem deve emitir esse fato, nem o que acontece quando uma credencial precisa ser revogada ou contestada. Tribunais, reguladores e instituições ainda precisam concordar que essas provas têm algum significado legal. Essa lacuna entre “a matemática funciona” e “a lei reconhece isso” ainda é grande na maior parte dos lugares.
Então eu não estou totalmente convencido, só curioso. Vale a pena se aprofundar nos documentos reais do protocolo antes de confiar no discurso. Continuo aprendendo, continuo questionando — um whitepaper de cada vez.
@Dusk #dusk $DUSK
Verificado
Tenho ficado com algo do whitepaper da Dusk Network que não tem nada a ver com a criptografia. Eles construíram dois sistemas de transação separados—um para privacidade e outro para conformidade—porque nenhum dos dois modelos sozinho poderia fazer ambos os trabalhos. Essa separação diz mais sobre onde o blockchain está do que qualquer recurso isolado. Um sistema financeiro regulado precisa de visibilidade suficiente para responsabilizar as pessoas—verificando quem está transacionando, registrando mudanças de titularidade e reconstruindo registros quando um regulador solicita. Já um usuário, por sua vez, não quer que cada transferência fique em exibição pública para sempre. A maioria das blockchains escolhe um lado—Bitcoin escolheu visibilidade, Monero escolheu privacidade. A resposta da Dusk tenta não ir a extremos: manter saldos e verificações de identidade por trás de uma estrutura em que apenas um resumo criptográfico vai a público, enquanto uma parte indicada pode reconstruir o quadro completo se a conformidade exigir. É isso que faz parecer mais fundamentado do que muitas alegações em cripto—não é “confie em nós”, é uma tentativa real de atender categorias legais como lista de investidores aprovados e trilhas de auditoria que reguladores pedem. Mas eu continuo voltando às lacunas. O próprio whitepaper aponta para um documento separado para o padrão real de conformidade, ou seja, este texto mostra a forma técnica da conformidade, não prova que algum regulador tenha aceitado isso. E a “parte indicada” que consegue ver tudo ainda é uma suposição de confiança, só que mais estreita. A visibilidade seletiva é, de fato, um caminho do meio genuinamente interessante. Se isso se sustenta depende da infraestrutura de identidade, do reconhecimento legal e da aplicação—nenhuma dessas coisas um whitepaper consegue resolver por conta própria. Vale a pena ler as fontes primárias por conta própria antes de decidir no que acreditar. Esse ainda é o hábito mais útil—questionar conclusões, inclusive as minhas, e continuar aprendendo ao longo do caminho. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Tenho ficado com algo do whitepaper da Dusk Network que não tem nada a ver com a criptografia. Eles construíram dois sistemas de transação separados—um para privacidade e outro para conformidade—porque nenhum dos dois modelos sozinho poderia fazer ambos os trabalhos. Essa separação diz mais sobre onde o blockchain está do que qualquer recurso isolado.

Um sistema financeiro regulado precisa de visibilidade suficiente para responsabilizar as pessoas—verificando quem está transacionando, registrando mudanças de titularidade e reconstruindo registros quando um regulador solicita. Já um usuário, por sua vez, não quer que cada transferência fique em exibição pública para sempre. A maioria das blockchains escolhe um lado—Bitcoin escolheu visibilidade, Monero escolheu privacidade. A resposta da Dusk tenta não ir a extremos: manter saldos e verificações de identidade por trás de uma estrutura em que apenas um resumo criptográfico vai a público, enquanto uma parte indicada pode reconstruir o quadro completo se a conformidade exigir.

É isso que faz parecer mais fundamentado do que muitas alegações em cripto—não é “confie em nós”, é uma tentativa real de atender categorias legais como lista de investidores aprovados e trilhas de auditoria que reguladores pedem.

Mas eu continuo voltando às lacunas. O próprio whitepaper aponta para um documento separado para o padrão real de conformidade, ou seja, este texto mostra a forma técnica da conformidade, não prova que algum regulador tenha aceitado isso. E a “parte indicada” que consegue ver tudo ainda é uma suposição de confiança, só que mais estreita.

A visibilidade seletiva é, de fato, um caminho do meio genuinamente interessante. Se isso se sustenta depende da infraestrutura de identidade, do reconhecimento legal e da aplicação—nenhuma dessas coisas um whitepaper consegue resolver por conta própria.

Vale a pena ler as fontes primárias por conta própria antes de decidir no que acreditar. Esse ainda é o hábito mais útil—questionar conclusões, inclusive as minhas, e continuar aprendendo ao longo do caminho.
@Dusk #dusk $DUSK
Verificado
Eu continuo voltando a uma frase em uma whitepaper da Dusk: "maioria honesta do dinheiro." Não a maioria honesta de pessoas. Não validadores honestos. Dinheiro. É uma frase curta, mas diz muita coisa quando você realmente para para pensar. Um protocolo não consegue olhar dentro da cabeça de alguém para verificar se essa pessoa é confiável. Ele não tem como medir a honestidade diretamente. Então ele mede a única coisa que consegue — quanto valor alguém perderia ao trapacear — e trata isso como segurança. Essa substituição importa mais aqui do que na maioria dos projetos, porque a Dusk não está construindo apenas mais uma cadeia — ela está mirando em ativos regulados e produtos licenciados, o tipo de infraestrutura que, eventualmente, encontra auditores e a legislação financeira real, e não só os primeiros adeptos. Tratar "capital em risco" como prova de "confiável o bastante para aquele mundo" é uma alegação maior do que parece. Vale a pena questionar isso com honestidade também. Muitas pessoas ricas e instituições agiram contra seu próprio interesse de longo prazo, apesar de terem muito a perder. O capital também pode se concentrar com o tempo, via exchanges ou grandes detentores, até que "maioria do dinheiro" silenciosamente vire um punhado de atores bem financiados. E se essa suposição econômica algum dia for tratada como substituta de responsabilidade legal de verdade, em vez de um apoio a ela, a diferença entre teoria e supervisão real é onde as coisas podem dar errado. Nada disso torna o modelo errado — é apenas uma aposta em incentivos, não uma garantia, e vale mais ser entendida do que confiada de fé. Quanto mais eu mergulho nesses sistemas, mais acho que a habilidade real é continuar curioso sobre o que está por baixo do design, e não apenas sobre o que foi prometido por cima. Ainda aprendendo, uma whitepaper de cada vez. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Eu continuo voltando a uma frase em uma whitepaper da Dusk: "maioria honesta do dinheiro." Não a maioria honesta de pessoas. Não validadores honestos. Dinheiro. É uma frase curta, mas diz muita coisa quando você realmente para para pensar.

Um protocolo não consegue olhar dentro da cabeça de alguém para verificar se essa pessoa é confiável. Ele não tem como medir a honestidade diretamente. Então ele mede a única coisa que consegue — quanto valor alguém perderia ao trapacear — e trata isso como segurança.

Essa substituição importa mais aqui do que na maioria dos projetos, porque a Dusk não está construindo apenas mais uma cadeia — ela está mirando em ativos regulados e produtos licenciados, o tipo de infraestrutura que, eventualmente, encontra auditores e a legislação financeira real, e não só os primeiros adeptos. Tratar "capital em risco" como prova de "confiável o bastante para aquele mundo" é uma alegação maior do que parece.

Vale a pena questionar isso com honestidade também. Muitas pessoas ricas e instituições agiram contra seu próprio interesse de longo prazo, apesar de terem muito a perder. O capital também pode se concentrar com o tempo, via exchanges ou grandes detentores, até que "maioria do dinheiro" silenciosamente vire um punhado de atores bem financiados. E se essa suposição econômica algum dia for tratada como substituta de responsabilidade legal de verdade, em vez de um apoio a ela, a diferença entre teoria e supervisão real é onde as coisas podem dar errado.

Nada disso torna o modelo errado — é apenas uma aposta em incentivos, não uma garantia, e vale mais ser entendida do que confiada de fé. Quanto mais eu mergulho nesses sistemas, mais acho que a habilidade real é continuar curioso sobre o que está por baixo do design, e não apenas sobre o que foi prometido por cima.

Ainda aprendendo, uma whitepaper de cada vez.
@Dusk #dusk $DUSK
Verificado
Eu estava lendo um artigo sobre blockchain desenvolvido para tokens de segurança, e um detalhe me fez parar: o sistema foi projetado para que você possa provar que tem permissão para deter um ativo sem precisar provar quem você é. Não está escondendo a sua elegibilidade — está escondendo tudo o resto sobre você, enquanto a elegibilidade em si continua sendo verificada. Essa diferença parece maior do que soa. A maior parte do discurso sobre privacidade em cripto trata de ocultar transações de estranhos. Aqui o foco é algo mais específico — a legislação de valores mobiliários de verdade. O projeto, Dusk Network, constrói seu modelo de privacidade em torno de um padrão de Confidential Security Contract, voltado para atender requisitos concretos como lista de permissões (whitelisting) e rastreamento do ciclo de vida, em vez de evitá-los. É isso que faz parecer menos um truque de privacidade e mais algo elaborado com reguladores em mente. Ainda assim, eu continuo voltando a uma lacuna. Alguém precisa decidir quem entra na lista de permissões em primeiro lugar, e essa parte ainda precisa das suas informações pessoais para tomar a decisão. A cadeia oculta sua identidade dos outros usuários, mas não remove o ponto de verificação em que um humano confirma que você é uma pessoa legítima e elegível. A prova cobre apenas o que acontece depois desse portão — não o portão em si, nem quem está do lado de lá. Então eu não leio isso como um problema já resolvido. Eu leio como uma redução significativa do que precisa ser exposto, mas com a pergunta mais difícil — quem detém o portão e o que mantém essa pessoa honesta — ainda fora do código. Nova criptografia não significa automaticamente nova responsabilidade. Vale a pena ler devagar e manter um pouco de ceticismo — esse hábito, mais do que qualquer whitepaper em si, é o que realmente ajuda você a crescer nesse espaço. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Eu estava lendo um artigo sobre blockchain desenvolvido para tokens de segurança, e um detalhe me fez parar: o sistema foi projetado para que você possa provar que tem permissão para deter um ativo sem precisar provar quem você é. Não está escondendo a sua elegibilidade — está escondendo tudo o resto sobre você, enquanto a elegibilidade em si continua sendo verificada.

Essa diferença parece maior do que soa. A maior parte do discurso sobre privacidade em cripto trata de ocultar transações de estranhos. Aqui o foco é algo mais específico — a legislação de valores mobiliários de verdade. O projeto, Dusk Network, constrói seu modelo de privacidade em torno de um padrão de Confidential Security Contract, voltado para atender requisitos concretos como lista de permissões (whitelisting) e rastreamento do ciclo de vida, em vez de evitá-los. É isso que faz parecer menos um truque de privacidade e mais algo elaborado com reguladores em mente.

Ainda assim, eu continuo voltando a uma lacuna. Alguém precisa decidir quem entra na lista de permissões em primeiro lugar, e essa parte ainda precisa das suas informações pessoais para tomar a decisão. A cadeia oculta sua identidade dos outros usuários, mas não remove o ponto de verificação em que um humano confirma que você é uma pessoa legítima e elegível. A prova cobre apenas o que acontece depois desse portão — não o portão em si, nem quem está do lado de lá.

Então eu não leio isso como um problema já resolvido. Eu leio como uma redução significativa do que precisa ser exposto, mas com a pergunta mais difícil — quem detém o portão e o que mantém essa pessoa honesta — ainda fora do código. Nova criptografia não significa automaticamente nova responsabilidade.

Vale a pena ler devagar e manter um pouco de ceticismo — esse hábito, mais do que qualquer whitepaper em si, é o que realmente ajuda você a crescer nesse espaço.
@Dusk #dusk $DUSK
@Dusk_Foundation #dusk $DUSK Eu costumava achar que uma blockchain focada em privacidade significava que tudo nela deveria ser privado por padrão. Parecia que esse era exatamente o ponto. Mas a Dusk na verdade executa dois modelos de transação lado a lado. A Phoenix lida com transferências protegidas. A Moonlight lida com as transparentes e públicas. Mesma cadeia, mesma camada de liquidação, dois padrões diferentes dependendo do que o caso de uso precisa. Foi isso que mudou meu raciocínio. Um mercado regulado não é uma coisa só. Alguns fluxos precisam permanecer confidenciais. Outros precisam ser verificáveis por qualquer pessoa a qualquer momento. Se uma cadeia oferece apenas um modo, ela já está forçando cada aplicação a um formato que não vai se encaixar em metade delas. Ainda não sei, na prática, o quão bem essa divisão funciona, se os desenvolvedores naturalmente recorrem ao modelo certo ou se acabam optando pelo que for mais fácil de implementar por padrão. É a parte que eu quero observar de novo quando mais aplicações realmente escolherem uma. {spot}(DUSKUSDT)
@Dusk #dusk $DUSK
Eu costumava achar que uma blockchain focada em privacidade significava que tudo nela deveria ser privado por padrão. Parecia que esse era exatamente o ponto.
Mas a Dusk na verdade executa dois modelos de transação lado a lado. A Phoenix lida com transferências protegidas. A Moonlight lida com as transparentes e públicas. Mesma cadeia, mesma camada de liquidação, dois padrões diferentes dependendo do que o caso de uso precisa.
Foi isso que mudou meu raciocínio. Um mercado regulado não é uma coisa só. Alguns fluxos precisam permanecer confidenciais. Outros precisam ser verificáveis por qualquer pessoa a qualquer momento. Se uma cadeia oferece apenas um modo, ela já está forçando cada aplicação a um formato que não vai se encaixar em metade delas.
Ainda não sei, na prática, o quão bem essa divisão funciona, se os desenvolvedores naturalmente recorrem ao modelo certo ou se acabam optando pelo que for mais fácil de implementar por padrão. É a parte que eu quero observar de novo quando mais aplicações realmente escolherem uma.
Confidential
100%
Transparent
0%
Both
0%
1 Votos • Votação encerrada
Parcialmente verdadeiro
@Dusk_Foundation Algo no whitepaper da Dusk me surpreendeu: ele admite abertamente uma falha no próprio design, em vez de apenas vender a visão. Geradores de blocos são escolhidos por uma fórmula determinística, então um provisioner às vezes consegue saber com antecedência que eles estão alinhados para uma tentativa posterior no mesmo bloco se as tentativas anteriores falharem — o que cria um incentivo estranho para simplesmente deixar essas tentativas colapsarem. O artigo chama isso de problema do incentivo ao gerador futuro e, em vez de passar por cima disso, oferece correções reais: recompensar pessoas apenas por votar, vincular parte do prêmio de um gerador à quantidade de votos que elas incluem e manter o gerador seguinte da fila fora do voto atual. Esse tipo de honestidade parece voltado a pessoas que auditam sistemas para viver, não a pessoas que perseguem uma narrativa — o que combina com a proposta completa da Dusk para finanças reguladas. Ainda assim, uma correção não é uma solução. Recompensas fazem as pessoas ajustarem o comportamento, mas não removem a previsibilidade subjacente, e um provisioner bem financiado que não se importa com reputação ainda poderia decidir que o risco vale a pena. É o mesmo tipo de lacuna que aparece entre código e lei: um protocolo pode tornar comportamentos ruins caros, mas só um tribunal ou regulador pode torná-los consequentes, não importa o quão fundos sejam os bolsos de alguém. Nada disso torna a abordagem da Dusk menos cuidadosa; apenas significa que a parte interessante de um whitepaper muitas vezes é o parágrafo que admite uma fraqueza, e não o que vende o resultado. Leia os limites que um projeto define para si mesmo e então decida quanto do resto vale confiar. Continuo aprendendo isso um paper de cada vez, e honestamente é essa a parte divertida. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
@Dusk
Algo no whitepaper da Dusk me surpreendeu: ele admite abertamente uma falha no próprio design, em vez de apenas vender a visão. Geradores de blocos são escolhidos por uma fórmula determinística, então um provisioner às vezes consegue saber com antecedência que eles estão alinhados para uma tentativa posterior no mesmo bloco se as tentativas anteriores falharem — o que cria um incentivo estranho para simplesmente deixar essas tentativas colapsarem.
O artigo chama isso de problema do incentivo ao gerador futuro e, em vez de passar por cima disso, oferece correções reais: recompensar pessoas apenas por votar, vincular parte do prêmio de um gerador à quantidade de votos que elas incluem e manter o gerador seguinte da fila fora do voto atual. Esse tipo de honestidade parece voltado a pessoas que auditam sistemas para viver, não a pessoas que perseguem uma narrativa — o que combina com a proposta completa da Dusk para finanças reguladas.
Ainda assim, uma correção não é uma solução. Recompensas fazem as pessoas ajustarem o comportamento, mas não removem a previsibilidade subjacente, e um provisioner bem financiado que não se importa com reputação ainda poderia decidir que o risco vale a pena. É o mesmo tipo de lacuna que aparece entre código e lei: um protocolo pode tornar comportamentos ruins caros, mas só um tribunal ou regulador pode torná-los consequentes, não importa o quão fundos sejam os bolsos de alguém.
Nada disso torna a abordagem da Dusk menos cuidadosa; apenas significa que a parte interessante de um whitepaper muitas vezes é o parágrafo que admite uma fraqueza, e não o que vende o resultado. Leia os limites que um projeto define para si mesmo e então decida quanto do resto vale confiar.
Continuo aprendendo isso um paper de cada vez, e honestamente é essa a parte divertida.
@Dusk #dusk $DUSK
A maior parte do whitepaper de Dusk foi criada para impressionar: uma atestação concisa, prometendo finalização em segundos, com dois modelos Moonlight-Phoenix que permitem que pagamentos transparentes e ofuscados coexistam. Perto do fim, sob uma seção intitulada "Other contracts," há algo mais discreto, que pode importar tanto quanto para a missão real da Dusk: o contrato Citadel, que governa licenças. No papel, o trabalho dele parece administrativo. O contrato emite licenças, acompanha quem detém cada uma, se elas estão válidas no momento e quando expiram, e então restringe certas operações a detentores de licenças válidas. Revogação e renovação funcionam do mesmo modo — como lógica contínua do contrato, e não como uma verificação única feita fora da cadeia. O que torna isso digno de uma segunda olhada é o que ele executa. Citadel é o próprio sistema de identidade com zero conhecimento da Dusk, descrito pela equipe como uma solução de KYC com zero conhecimento. O artigo de pesquisa aponta uma fraqueza real em designs anteriores: os direitos de um usuário — uma assinatura, um ingresso, autorização para negociar — eram representados como um NFT comprovado via prova de zero conhecimento, mas o NFT permanecia público e rastreável, silenciosamente desfazendo aquela privacidade. A Citadel mantém o direito privado também; então uma licença construída sobre isso pode permitir que alguém mostre que possui uma licença válida e não expirada sem expor qual é ela, quem a emitiu, ou quem é essa pessoa. Isso é uma resposta genuinamente diferente ao impasse privacidade versus conformidade da blockchain do par usual: transparência total, como na Ethereum, ou anonimato pessoal, como na Monero. Mercados regulados, em tese, precisam de uma terceira opção — elegibilidade demonstrável sem uma identidade pública anexada, reutilizável entre relacionamentos em vez de refazer KYC toda vez. Ao lado do Zedger, o vizinho focado em valores mobiliários, essa camada de licenças parece menos uma nota de rodapé administrativa e mais o mecanismo em que a Dusk está apostando para fazer privacidade e regulamentação coexistirem. @Dusk_Foundation #dusk $DUSK $ETH $XMR {future}(XMRUSDT) {spot}(ETHUSDT) {spot}(DUSKUSDT)
A maior parte do whitepaper de Dusk foi criada para impressionar: uma atestação concisa, prometendo finalização em segundos, com dois modelos Moonlight-Phoenix que permitem que pagamentos transparentes e ofuscados coexistam. Perto do fim, sob uma seção intitulada "Other contracts," há algo mais discreto, que pode importar tanto quanto para a missão real da Dusk: o contrato Citadel, que governa licenças.

No papel, o trabalho dele parece administrativo. O contrato emite licenças, acompanha quem detém cada uma, se elas estão válidas no momento e quando expiram, e então restringe certas operações a detentores de licenças válidas. Revogação e renovação funcionam do mesmo modo — como lógica contínua do contrato, e não como uma verificação única feita fora da cadeia.

O que torna isso digno de uma segunda olhada é o que ele executa. Citadel é o próprio sistema de identidade com zero conhecimento da Dusk, descrito pela equipe como uma solução de KYC com zero conhecimento. O artigo de pesquisa aponta uma fraqueza real em designs anteriores: os direitos de um usuário — uma assinatura, um ingresso, autorização para negociar — eram representados como um NFT comprovado via prova de zero conhecimento, mas o NFT permanecia público e rastreável, silenciosamente desfazendo aquela privacidade. A Citadel mantém o direito privado também; então uma licença construída sobre isso pode permitir que alguém mostre que possui uma licença válida e não expirada sem expor qual é ela, quem a emitiu, ou quem é essa pessoa.

Isso é uma resposta genuinamente diferente ao impasse privacidade versus conformidade da blockchain do par usual: transparência total, como na Ethereum, ou anonimato pessoal, como na Monero. Mercados regulados, em tese, precisam de uma terceira opção — elegibilidade demonstrável sem uma identidade pública anexada, reutilizável entre relacionamentos em vez de refazer KYC toda vez. Ao lado do Zedger, o vizinho focado em valores mobiliários, essa camada de licenças parece menos uma nota de rodapé administrativa e mais o mecanismo em que a Dusk está apostando para fazer privacidade e regulamentação coexistirem.
@Dusk #dusk
$DUSK
$ETH
$XMR

Tenho estado a analisar o whitepaper da Dusk esta semana, e uma linha fez-me parar: um smart contract que permite a um emissor forçar a transferência de um token de segurança para fora da carteira de alguém. O meu primeiro pensamento foi: "não é isso o oposto do que a cripto supostamente deve fazer?" Depois lembrei-me de que é assim que, na verdade, funciona a lei dos valores mobiliários. As empresas podem congelar ou reaver ações; dividendos são emitidos; e a titularidade é corrigida. Uma blockchain que hospeda ativos reais e regulados tem de abrir espaço para isso, não lutar contra isso. Foi isso que fez com que esta ideia me parecesse mais "real" do que a maioria dos projetos de privacidade que já li. A Dusk não está apenas a esconder os valores das transações — está a construir auditorias, um sistema de identidade e licenciamento chamado Citadel, e uma estrutura de valores mobiliários (Zedger) modelada sobre como as corporate actions já funcionam fora da cadeia. É menos "o código é a lei" e mais "o código tem de responder à lei", o que é algo muito mais difícil de conceber. Ainda assim, não estou totalmente convencido. Um whitepaper pode descrever um mecanismo de auditoria; não pode dizer-lhe se algum regulador vai tratar uma prova de conhecimento zero como evidência válida num caso real. Vários destes contratos são descritos como coisas que "serão" implantadas, e não como coisas a funcionar hoje. Conceber para conformidade e ser reconhecido legalmente como conforme são dois marcos bem diferentes, e o segundo normalmente leva anos, tribunais e disputas reais para ser resolvido. Por isso, estou a encarar isto como um dado interessante, não como uma conclusão. Vale a pena ler os contratos reais antes de assumir que "feito para reguladores" significa "aprovado por reguladores". Ainda estou a aprender quanto do que quer que seja isto sobrevive ao contacto com o mundo real, um projeto e um paper de cada vez. @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Tenho estado a analisar o whitepaper da Dusk esta semana, e uma linha fez-me parar: um smart contract que permite a um emissor forçar a transferência de um token de segurança para fora da carteira de alguém. O meu primeiro pensamento foi: "não é isso o oposto do que a cripto supostamente deve fazer?" Depois lembrei-me de que é assim que, na verdade, funciona a lei dos valores mobiliários. As empresas podem congelar ou reaver ações; dividendos são emitidos; e a titularidade é corrigida. Uma blockchain que hospeda ativos reais e regulados tem de abrir espaço para isso, não lutar contra isso.

Foi isso que fez com que esta ideia me parecesse mais "real" do que a maioria dos projetos de privacidade que já li. A Dusk não está apenas a esconder os valores das transações — está a construir auditorias, um sistema de identidade e licenciamento chamado Citadel, e uma estrutura de valores mobiliários (Zedger) modelada sobre como as corporate actions já funcionam fora da cadeia. É menos "o código é a lei" e mais "o código tem de responder à lei", o que é algo muito mais difícil de conceber.

Ainda assim, não estou totalmente convencido. Um whitepaper pode descrever um mecanismo de auditoria; não pode dizer-lhe se algum regulador vai tratar uma prova de conhecimento zero como evidência válida num caso real. Vários destes contratos são descritos como coisas que "serão" implantadas, e não como coisas a funcionar hoje. Conceber para conformidade e ser reconhecido legalmente como conforme são dois marcos bem diferentes, e o segundo normalmente leva anos, tribunais e disputas reais para ser resolvido.

Por isso, estou a encarar isto como um dado interessante, não como uma conclusão. Vale a pena ler os contratos reais antes de assumir que "feito para reguladores" significa "aprovado por reguladores". Ainda estou a aprender quanto do que quer que seja isto sobrevive ao contacto com o mundo real, um projeto e um paper de cada vez.
@Dusk #dusk $DUSK
No início, presumi que a seleção privada de líderes do Dusk era, em grande parte, sobre esconder quem tem permissão para propor o próximo bloco. Mas, quanto mais eu olhava, mais silenciosa parecia ser a dependência em outro lugar. Proof-of-Blind Bid permite que um participante calcule uma pontuação de líder a partir de uma oferta oculta e prove essa pontuação sem expor o valor da aposta ou a identidade. A parte que ficou comigo é como o sistema decide se essa pontuação é alta o suficiente. O whitepaper assume que um limite de pontuação é calculado dinamicamente para cada época, com o alvo ligado ao número médio de líderes esperado por etapa de rodada. Mas a função concreta do limiar é explicitamente deixada fora do escopo do documento. Isso não torna o mecanismo inconsistente. Significa, porém, que o comportamento de seleção de líderes depende de um processo de definição de parâmetros que fica fora do próprio prova criptográfica. Na prática, essa fronteira importa porque a seleção privada ainda precisa de uma ideia compartilhada sobre o que conta como líderes elegíveis suficientes. Então a pergunta real não é se a oferta está oculta. É quem define, no fim das contas, o limite contra o qual as ofertas ocultas são julgadas? #DuskNetwork #ProofOfStake $DUSK @Dusk_Foundation #dusk {spot}(DUSKUSDT)
No início, presumi que a seleção privada de líderes do Dusk era, em grande parte, sobre esconder quem tem permissão para propor o próximo bloco. Mas, quanto mais eu olhava, mais silenciosa parecia ser a dependência em outro lugar. Proof-of-Blind Bid permite que um participante calcule uma pontuação de líder a partir de uma oferta oculta e prove essa pontuação sem expor o valor da aposta ou a identidade. A parte que ficou comigo é como o sistema decide se essa pontuação é alta o suficiente. O whitepaper assume que um limite de pontuação é calculado dinamicamente para cada época, com o alvo ligado ao número médio de líderes esperado por etapa de rodada. Mas a função concreta do limiar é explicitamente deixada fora do escopo do documento. Isso não torna o mecanismo inconsistente. Significa, porém, que o comportamento de seleção de líderes depende de um processo de definição de parâmetros que fica fora do próprio prova criptográfica. Na prática, essa fronteira importa porque a seleção privada ainda precisa de uma ideia compartilhada sobre o que conta como líderes elegíveis suficientes. Então a pergunta real não é se a oferta está oculta. É quem define, no fim das contas, o limite contra o qual as ofertas ocultas são julgadas?

#DuskNetwork #ProofOfStake $DUSK @Dusk #dusk
No começo, presumi que a “vivacidade” no consenso de Dusk era apenas uma função de participação e de stake — bastava haver provisioners honestos online, e a cadeia continuaria a avançar por conta própria. Mas, quanto mais eu analisei a seção do modo de emergência, mais o quadro ficou silencioso em relação a isso. Quando falham iterações consecutivas suficientes e nenhum candidato alcança quórum, a rede não fica apenas tentando indefinidamente nos seus próprios termos. Os provisioners podem solicitar um bloco de emergência, e a produção dele depende de uma seed assinada por uma chave que o artigo simplesmente chama de “Dusk”, verificada em relação a uma chave pública listada como um parâmetro global. A própria solicitação precisa de uma maioria do peso alocado (staked) por trás dela, então não é unilateral. Ainda assim, o fallback para o pior caso do sistema acaba sendo direcionado por meio de uma única parte específica, nomeada, em vez da ordenação (sortition) aberta usada em todos os outros casos. Talvez seja uma troca razoável para uma cadeia construída em torno de finanças reguladas. Fico me perguntando se a descentralização é melhor avaliada pelo caso comum, ou pelo que acontece quando o caso comum se rompe. #dusk #Consensus @Dusk_Foundation $DUSK {spot}(DUSKUSDT)
No começo, presumi que a “vivacidade” no consenso de Dusk era apenas uma função de participação e de stake — bastava haver provisioners honestos online, e a cadeia continuaria a avançar por conta própria. Mas, quanto mais eu analisei a seção do modo de emergência, mais o quadro ficou silencioso em relação a isso. Quando falham iterações consecutivas suficientes e nenhum candidato alcança quórum, a rede não fica apenas tentando indefinidamente nos seus próprios termos. Os provisioners podem solicitar um bloco de emergência, e a produção dele depende de uma seed assinada por uma chave que o artigo simplesmente chama de “Dusk”, verificada em relação a uma chave pública listada como um parâmetro global. A própria solicitação precisa de uma maioria do peso alocado (staked) por trás dela, então não é unilateral. Ainda assim, o fallback para o pior caso do sistema acaba sendo direcionado por meio de uma única parte específica, nomeada, em vez da ordenação (sortition) aberta usada em todos os outros casos. Talvez seja uma troca razoável para uma cadeia construída em torno de finanças reguladas. Fico me perguntando se a descentralização é melhor avaliada pelo caso comum, ou pelo que acontece quando o caso comum se rompe.
#dusk #Consensus @Dusk $DUSK
Tenho lido sobre cofres de Bitcoin esta semana, e um número me parou: algo como 99% de todo o Bitcoin nunca toca a DeFi. Não porque as pessoas não queiram mais utilidade para ele, mas porque fazer qualquer coisa com ele em outro lugar geralmente significa confiar em um custodiante, uma ponte ou alguma empresa que guarda suas moedas em seu nome. É isso que faz o conceito de "cofre sem confiança" (trustless vault) do time da Babylon se destacar para mim. Em vez de depender da promessa de uma empresa, ou de um acordo legal que você teria que fazer cumprir em tribunal, as moedas ficam travadas de modo que só se movem quando condições específicas de prova são atendidas. Não há custodiante para falir, nem operador de ponte para desaparecer de um dia para o outro. A proteção vem de como o sistema é construído, e não de um contrato guardado na gaveta de um advogado. Ainda assim, eu não quero me empolgar demais. "Sem confiança" não significa que nada possa dar errado. O sistema ainda depende de liquidadores honestos, de feeds de preços confiáveis e de pessoas gerenciando arquivos grandes corretamente nos bastidores. Nada disso vem com uma garantia legal. Se algo falhar fora da cadeia (off-chain), não existe regulador para você ligar e pedir reembolso. A distância entre "isso funciona em teoria" e "isso se sustenta com dinheiro real, em escala, por anos" ainda é muito concreta. Então eu estou genuinamente em dúvida por enquanto, e acho que isso é ok. Nem tudo que é novo precisa de um veredito instantâneo. O que eu continuo retomando é isto: entender como algo realmente funciona antes de decidir o que isso significa. Isso é verdadeiro aqui e, honestamente, em quase todo lugar. Continue curioso, faça perguntas e dê a si mesmo permissão para continuar aprendendo devagar. É geralmente aí que acontece o crescimento real, muito depois que a empolgação se dissipa. @babylonlabs_io #baby $BABY {spot}(BABYUSDT)
Tenho lido sobre cofres de Bitcoin esta semana, e um número me parou: algo como 99% de todo o Bitcoin nunca toca a DeFi. Não porque as pessoas não queiram mais utilidade para ele, mas porque fazer qualquer coisa com ele em outro lugar geralmente significa confiar em um custodiante, uma ponte ou alguma empresa que guarda suas moedas em seu nome.

É isso que faz o conceito de "cofre sem confiança" (trustless vault) do time da Babylon se destacar para mim. Em vez de depender da promessa de uma empresa, ou de um acordo legal que você teria que fazer cumprir em tribunal, as moedas ficam travadas de modo que só se movem quando condições específicas de prova são atendidas. Não há custodiante para falir, nem operador de ponte para desaparecer de um dia para o outro. A proteção vem de como o sistema é construído, e não de um contrato guardado na gaveta de um advogado.

Ainda assim, eu não quero me empolgar demais. "Sem confiança" não significa que nada possa dar errado. O sistema ainda depende de liquidadores honestos, de feeds de preços confiáveis e de pessoas gerenciando arquivos grandes corretamente nos bastidores. Nada disso vem com uma garantia legal. Se algo falhar fora da cadeia (off-chain), não existe regulador para você ligar e pedir reembolso. A distância entre "isso funciona em teoria" e "isso se sustenta com dinheiro real, em escala, por anos" ainda é muito concreta.

Então eu estou genuinamente em dúvida por enquanto, e acho que isso é ok. Nem tudo que é novo precisa de um veredito instantâneo.

O que eu continuo retomando é isto: entender como algo realmente funciona antes de decidir o que isso significa. Isso é verdadeiro aqui e, honestamente, em quase todo lugar. Continue curioso, faça perguntas e dê a si mesmo permissão para continuar aprendendo devagar. É geralmente aí que acontece o crescimento real, muito depois que a empolgação se dissipa.
@BabylonLabs_io #baby $BABY
Tenho lido o novo whitepaper da Babylon sobre vaults de Bitcoin sem confiança, e um detalhe ficou em mim mais do que a criptografia: eles deliberadamente não chamam isso de bridge (ponte). Isso não é só branding. Bridges exigem que exista alguém no meio — operadores, signers (assinantes), challengers (contestadores) — e o histórico nos mostra repetidamente o quão mal esse “meio” pode falhar. O que a Babylon está propondo em vez disso é um vault vinculado a partes específicas e conhecidas, usando transações pré-assinadas e provas de conhecimento zero, de modo que o BTC nunca realmente saia da cadeia do Bitcoin para participar em outro lugar.#Babylon O que faz essa abordagem parecer mais fundamentada do que a maioria dos anúncios cripto é que não é apenas um conceito — já está parcialmente comprovada. O protocolo subjacente de staking está em funcionamento desde 2024 e tem bilhões em BTC real bloqueado por meio dele. Esse histórico pesa mais para mim do que qualquer slide de roadmap. Isso sugere que a equipe está estendendo algo testado, e não lançando uma promessa nova. Ainda assim, eu manteria meu otimismo com folga. Trust-minimized (minimizando a confiança) não é o mesmo que isento de risco. Se alguma disputa alguma vez for contestada, ainda será necessário que alguém gere uma prova, armazene circuitos grandes e corrompidos (“garbled circuits”) e responda corretamente dentro de uma janela de timeout. Isso exige bastante coordenação apoiada em indivíduos ou operadores pequenos — e coordenação é exatamente onde sistemas tendem a quebrar sob pressão. Também existe a pergunta em aberto sobre como liquidadores, credores e smart contracts entre cadeias diferentes são realmente regulados quando algo dá errado financeiramente. Então eu não estou pronto para chamar isso de “resolvido”. Estou chamando de algo que vale a pena acompanhar de perto. Se existe um hábito que o mundo cripto continua me ensinando, é este: entender o mecanismo antes de confiar no resultado. Sistemas evoluem, incentivos mudam, e um design “esperto” de hoje pode virar um caso limite de amanhã. Manter-se curioso, fazer perguntas desconfortáveis e construir entendimento real aos poucos vence a confiança cega — toda vez. @babylonlabs_io #baby $BABY @bitcoin #bitcoin #BTC $BTC {spot}(BTCUSDT) {spot}(BABYUSDT)
Tenho lido o novo whitepaper da Babylon sobre vaults de Bitcoin sem confiança, e um detalhe ficou em mim mais do que a criptografia: eles deliberadamente não chamam isso de bridge (ponte). Isso não é só branding. Bridges exigem que exista alguém no meio — operadores, signers (assinantes), challengers (contestadores) — e o histórico nos mostra repetidamente o quão mal esse “meio” pode falhar. O que a Babylon está propondo em vez disso é um vault vinculado a partes específicas e conhecidas, usando transações pré-assinadas e provas de conhecimento zero, de modo que o BTC nunca realmente saia da cadeia do Bitcoin para participar em outro lugar.#Babylon
O que faz essa abordagem parecer mais fundamentada do que a maioria dos anúncios cripto é que não é apenas um conceito — já está parcialmente comprovada. O protocolo subjacente de staking está em funcionamento desde 2024 e tem bilhões em BTC real bloqueado por meio dele. Esse histórico pesa mais para mim do que qualquer slide de roadmap. Isso sugere que a equipe está estendendo algo testado, e não lançando uma promessa nova.
Ainda assim, eu manteria meu otimismo com folga. Trust-minimized (minimizando a confiança) não é o mesmo que isento de risco. Se alguma disputa alguma vez for contestada, ainda será necessário que alguém gere uma prova, armazene circuitos grandes e corrompidos (“garbled circuits”) e responda corretamente dentro de uma janela de timeout. Isso exige bastante coordenação apoiada em indivíduos ou operadores pequenos — e coordenação é exatamente onde sistemas tendem a quebrar sob pressão. Também existe a pergunta em aberto sobre como liquidadores, credores e smart contracts entre cadeias diferentes são realmente regulados quando algo dá errado financeiramente.
Então eu não estou pronto para chamar isso de “resolvido”. Estou chamando de algo que vale a pena acompanhar de perto.
Se existe um hábito que o mundo cripto continua me ensinando, é este: entender o mecanismo antes de confiar no resultado. Sistemas evoluem, incentivos mudam, e um design “esperto” de hoje pode virar um caso limite de amanhã. Manter-se curioso, fazer perguntas desconfortáveis e construir entendimento real aos poucos vence a confiança cega — toda vez.
@BabylonLabs_io #baby $BABY
@Bitcoin #bitcoin #BTC $BTC
Estava lendo um artigo sobre cofres de Bitcoin na semana passada, e uma palavra ficou chamando minha atenção: "trustless". Não porque seja um termo novo, mas porque comecei a pensar no que isso realmente significa quando estão envolvidos dinheiro de verdade, disputas de verdade e pessoas de verdade. A ideia central é elegante: em vez de entregar o Bitcoin a um custodiante ou a uma ponte e torcer para que eles se comportem, você o tranca em um cofre, onde provas criptográficas determinam quem pode sacar — não uma empresa, não um comitê. É isso que faz parecer mais "real" para mim do que a maioria das promessas no mundo cripto. E não está acontecendo no vácuo. Este ano, tanto a SEC quanto a CFTC começaram a escrever orientações reais sobre ferramentas de auto-custódia e o uso de cripto como garantia em mercados regulados. Esse é um sinal concreto: reguladores não estão mais ignorando isso; eles estão tentando encaixar isso na legislação existente.#Babylon Mas é aqui que continuo cauteloso. Escrever orientações não é a mesma coisa que escrever certeza. Se um sistema de provas tiver um bug, ou se duas partes discordarem do que conta como "válido", ainda não existe um roteiro claro sobre o que acontece em seguida. O código pode impor uma regra, mas ainda não consegue substituir um tribunal, um processo de disputa ou uma proteção básica ao consumidor. Essa lacuna entre o que a tecnologia consegue fazer e o que a lei consegue sustentar não foi preenchida — apenas ficou mais visível. Então fico curioso, não convencido. Sistemas criados para reduzir a confiança cega valem ser entendidos profundamente — não aplaudidos cegamente. Questione os mecanismos, não apenas a propaganda. Essa é, de fato, a lição maior: mantenha a curiosidade, continue aprendendo e deixe seu entendimento crescer junto com a tecnologia, em vez de correr na frente dela. @babylonlabs_io #baby $BABY @bitcoin #bitcoin #BTC $BTC {spot}(BTCUSDT) {spot}(BABYUSDT)
Estava lendo um artigo sobre cofres de Bitcoin na semana passada, e uma palavra ficou chamando minha atenção: "trustless". Não porque seja um termo novo, mas porque comecei a pensar no que isso realmente significa quando estão envolvidos dinheiro de verdade, disputas de verdade e pessoas de verdade.

A ideia central é elegante: em vez de entregar o Bitcoin a um custodiante ou a uma ponte e torcer para que eles se comportem, você o tranca em um cofre, onde provas criptográficas determinam quem pode sacar — não uma empresa, não um comitê. É isso que faz parecer mais "real" para mim do que a maioria das promessas no mundo cripto. E não está acontecendo no vácuo. Este ano, tanto a SEC quanto a CFTC começaram a escrever orientações reais sobre ferramentas de auto-custódia e o uso de cripto como garantia em mercados regulados. Esse é um sinal concreto: reguladores não estão mais ignorando isso; eles estão tentando encaixar isso na legislação existente.#Babylon

Mas é aqui que continuo cauteloso. Escrever orientações não é a mesma coisa que escrever certeza. Se um sistema de provas tiver um bug, ou se duas partes discordarem do que conta como "válido", ainda não existe um roteiro claro sobre o que acontece em seguida. O código pode impor uma regra, mas ainda não consegue substituir um tribunal, um processo de disputa ou uma proteção básica ao consumidor. Essa lacuna entre o que a tecnologia consegue fazer e o que a lei consegue sustentar não foi preenchida — apenas ficou mais visível.

Então fico curioso, não convencido. Sistemas criados para reduzir a confiança cega valem ser entendidos profundamente — não aplaudidos cegamente. Questione os mecanismos, não apenas a propaganda. Essa é, de fato, a lição maior: mantenha a curiosidade, continue aprendendo e deixe seu entendimento crescer junto com a tecnologia, em vez de correr na frente dela.
@BabylonLabs_io #baby $BABY
@Bitcoin #bitcoin #BTC $BTC
No começo, assumi que o detalhe de que “cada parte gera um circuito uma vez por contraparte” no modelo de custos do BitVM3 era apenas uma nota de otimização. Mas quanto mais eu olhava, mais percebia que o mecanismo que faz o trabalho de verdade aqui é a desqualificação, não o custo de geração. Um desafio malsucedido não apenas resolve uma disputa — ele remove essa parte totalmente de futuras retiradas do vault. É isso que permite que a geração de circuito seja amortizada em vez de repetida por cada depósito. O que chamou minha atenção é o quanto o sistema deposita o peso sobre “operadores profissionais”, para os quais se espera que tomadores menores deleguem. Eles não conseguem roubar BTC, já que o tomador ainda coassina, mas podem acumular exposição por meio de muitas contrapartes, cada uma individualmente confiando em uma regra de desqualificação que não foi desenhada por elas. O modelo de segurança assume que perder uma vez é suficiente como fator de dissuasão. Talvez isso seja razoável para um operador racional que gerencia reputação. O que deixa a questão mais silenciosa: se um sistema que trata “ser pego uma vez” como punição suficiente está descrevendo o comportamento de operadores ou apenas apostando nisso. #bitcoin #defi #BitVM $BABY @babylonlabs_io #baby $BTC {spot}(BTCUSDT) {spot}(BABYUSDT)
No começo, assumi que o detalhe de que “cada parte gera um circuito uma vez por contraparte” no modelo de custos do BitVM3 era apenas uma nota de otimização. Mas quanto mais eu olhava, mais percebia que o mecanismo que faz o trabalho de verdade aqui é a desqualificação, não o custo de geração. Um desafio malsucedido não apenas resolve uma disputa — ele remove essa parte totalmente de futuras retiradas do vault. É isso que permite que a geração de circuito seja amortizada em vez de repetida por cada depósito. O que chamou minha atenção é o quanto o sistema deposita o peso sobre “operadores profissionais”, para os quais se espera que tomadores menores deleguem. Eles não conseguem roubar BTC, já que o tomador ainda coassina, mas podem acumular exposição por meio de muitas contrapartes, cada uma individualmente confiando em uma regra de desqualificação que não foi desenhada por elas. O modelo de segurança assume que perder uma vez é suficiente como fator de dissuasão. Talvez isso seja razoável para um operador racional que gerencia reputação. O que deixa a questão mais silenciosa: se um sistema que trata “ser pego uma vez” como punição suficiente está descrevendo o comportamento de operadores ou apenas apostando nisso.
#bitcoin #defi #BitVM $BABY @BabylonLabs_io #baby $BTC
Volto sempre a uma pergunta que a maioria dos explicadores de cripto ignora: quando algo dá errado, quem realmente assume o risco? Não na teoria — nos detalhes do contrato. Essa pergunta foi o que tornou este paper específico de um cofre de Bitcoin interessante para mim. A maioria dos projetos de pontes depende silenciosamente de um comitê ou de um conjunto de “operadores” que, em tese, poderiam se conluiar e sair com os fundos. Este desenho tenta algo diferente: em vez de entregar a custódia a um terceiro, duas pessoas pré-assinam diretamente as condições exatas sob as quais os fundos se movem, e uma prova criptográfica — e não a palavra de uma pessoa — decide quem está certo. No papel, isso cria um modelo de risco de forma significativamente diferente de “confie nesse multisig.”#Babylon O que faz com que pareça mais fundamentado do que a maioria das apresentações é a honestidade com que é apresentado. Há uma tabela comparativa real, mostrando, caso a caso, exatamente qual parte ainda precisa confiar em quem em cada desenho — incluindo a própria. Isso é raro. A maioria dos projetos vende certeza; este mostra onde a confiança restante ainda está depositada. Ainda assim, eu não acho que “menos humanos no circuito” signifique automaticamente “sem risco”. Oráculos podem estar errados. Liquidadores podem ser lentos ou ausentes. E um sistema pode ser criptograficamente sólido, mas ainda assim ser operacionalmente frágil — não testado em escala, sob estresse real de mercado, com dinheiro de verdade entrando em pânico em tempo real. Então eu ainda não estou pronto para chamar isso de resolvido. Só estou feliz por alguém ter registrado onde a confiança realmente vive, em vez de escondê-la. Vale lembrar: entender os limites de um sistema ainda é progresso, mesmo sem uma conclusão arrumadinha. @babylonlabs_io #baby $BABY @bitcoin #bitcoin #BTC $BTC {spot}(BTCUSDT) {spot}(BABYUSDT)
Volto sempre a uma pergunta que a maioria dos explicadores de cripto ignora: quando algo dá errado, quem realmente assume o risco? Não na teoria — nos detalhes do contrato.
Essa pergunta foi o que tornou este paper específico de um cofre de Bitcoin interessante para mim. A maioria dos projetos de pontes depende silenciosamente de um comitê ou de um conjunto de “operadores” que, em tese, poderiam se conluiar e sair com os fundos. Este desenho tenta algo diferente: em vez de entregar a custódia a um terceiro, duas pessoas pré-assinam diretamente as condições exatas sob as quais os fundos se movem, e uma prova criptográfica — e não a palavra de uma pessoa — decide quem está certo. No papel, isso cria um modelo de risco de forma significativamente diferente de “confie nesse multisig.”#Babylon
O que faz com que pareça mais fundamentado do que a maioria das apresentações é a honestidade com que é apresentado. Há uma tabela comparativa real, mostrando, caso a caso, exatamente qual parte ainda precisa confiar em quem em cada desenho — incluindo a própria. Isso é raro. A maioria dos projetos vende certeza; este mostra onde a confiança restante ainda está depositada.
Ainda assim, eu não acho que “menos humanos no circuito” signifique automaticamente “sem risco”. Oráculos podem estar errados. Liquidadores podem ser lentos ou ausentes. E um sistema pode ser criptograficamente sólido, mas ainda assim ser operacionalmente frágil — não testado em escala, sob estresse real de mercado, com dinheiro de verdade entrando em pânico em tempo real.
Então eu ainda não estou pronto para chamar isso de resolvido. Só estou feliz por alguém ter registrado onde a confiança realmente vive, em vez de escondê-la.
Vale lembrar: entender os limites de um sistema ainda é progresso, mesmo sem uma conclusão arrumadinha.
@BabylonLabs_io #baby $BABY
@Bitcoin #bitcoin #BTC $BTC
Eu estava lendo o novo whitepaper da Babylon sobre cofres de Bitcoin e um detalhe ficou mais comigo do que a própria tecnologia: eles não estão construindo uma ponte. Eles dizem explicitamente que pontes são um workaround, não o objetivo — e depois de ver o quanto o BTC realmente entra na DeFi (menos de 1%), essa abordagem faz sentido. A maior parte do Bitcoin apenas fica lá, desconectada de tudo. O que faz isso parecer diferente de muitas propostas de cripto é que não está pedindo que você confie em uma empresa ou em um comitê. O design inteiro foi feito para remover essa camada — Bob e Larry, as duas partes no exemplo de empréstimo, pré-assinam transações para que nenhuma das partes consiga controlar silenciosamente os coins da outra. Nenhum custodiante guardando seu BTC “para sua segurança”. Nenhum token envolvido em que, na prática, você só está confiando em quem emitiu. Essa promessa é significativamente diferente da maioria dos produtos de ponte. Mas vou ser honesto: sou cauteloso em relação à distância entre “sem confiança na teoria” e “sem confiança na prática”. O próprio paper admite que custos reais surgem se houver disputas, e ele depende de infraestrutura off-chain — circuitos embaralhados, geração de provas, acesso a nós — que ainda precisa ser executada por alguém, corretamente, toda vez. Garantias criptográficas são tão fortes quanto o software que as implementa, e é geralmente aí que as coisas silenciosamente falham.#Babylon Então não estou descartando, mas também não estou totalmente convencido. É uma tentativa genuinamente interessante de resolver um problema real, em vez de passar por cima disso com mais um invólucro custodial. Se você está acompanhando esse segmento, vale a pena ler os mecanismos reais antes de decidir o que “sem confiança” significa para você de verdade. Diminua o ritmo, pergunte o que é assumido versus o que é provado, e continue aprendendo — esse hábito importa mais do que qualquer projeto isolado jamais vai importar. @babylonlabs_io #baby $BABY @bitcoin #bitcoin #BTC $BTC {spot}(BTCUSDT) {spot}(BABYUSDT)
Eu estava lendo o novo whitepaper da Babylon sobre cofres de Bitcoin e um detalhe ficou mais comigo do que a própria tecnologia: eles não estão construindo uma ponte. Eles dizem explicitamente que pontes são um workaround, não o objetivo — e depois de ver o quanto o BTC realmente entra na DeFi (menos de 1%), essa abordagem faz sentido. A maior parte do Bitcoin apenas fica lá, desconectada de tudo.
O que faz isso parecer diferente de muitas propostas de cripto é que não está pedindo que você confie em uma empresa ou em um comitê. O design inteiro foi feito para remover essa camada — Bob e Larry, as duas partes no exemplo de empréstimo, pré-assinam transações para que nenhuma das partes consiga controlar silenciosamente os coins da outra. Nenhum custodiante guardando seu BTC “para sua segurança”. Nenhum token envolvido em que, na prática, você só está confiando em quem emitiu. Essa promessa é significativamente diferente da maioria dos produtos de ponte.
Mas vou ser honesto: sou cauteloso em relação à distância entre “sem confiança na teoria” e “sem confiança na prática”. O próprio paper admite que custos reais surgem se houver disputas, e ele depende de infraestrutura off-chain — circuitos embaralhados, geração de provas, acesso a nós — que ainda precisa ser executada por alguém, corretamente, toda vez. Garantias criptográficas são tão fortes quanto o software que as implementa, e é geralmente aí que as coisas silenciosamente falham.#Babylon
Então não estou descartando, mas também não estou totalmente convencido. É uma tentativa genuinamente interessante de resolver um problema real, em vez de passar por cima disso com mais um invólucro custodial.
Se você está acompanhando esse segmento, vale a pena ler os mecanismos reais antes de decidir o que “sem confiança” significa para você de verdade. Diminua o ritmo, pergunte o que é assumido versus o que é provado, e continue aprendendo — esse hábito importa mais do que qualquer projeto isolado jamais vai importar.
@BabylonLabs_io #baby $BABY
@Bitcoin #bitcoin #BTC $BTC
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma