传奇FEEHA
10.5k Publicações
传奇FEEHA
Sharing crypto basics, market updates, and Web3 insights in simple language. My goal is to make trading concepts easy to understand, provide clear explanations.
1.3K+ Seguindo
15.0K+ Seguidores
8.6K+ Curtiu
Publicações
Todas
Vídeos
Live
@Dusk Então a pergunta interessante não é realmente “Privado ou transparente”?
É privado e transparente para quem e quando?
A Dusk é uma daquelas blockchains Layer1 com foco em privacidade, em que quanto mais tempo você gasta olhando “por baixo do capô”, mais a moldura privacidade versus transparência começa a parecer desatualizada.
A parte que realmente chamou minha atenção é que a Dusk não trata isso como um dilema de troca.
Aqui vai a sequência.
A maioria dos sistemas escolhe um lado.
Totalmente privado ou totalmente transparente.
A Dusk não força essa escolha.
A privacidade se aplica onde é necessária.
A transparência se aplica onde é útil.
A decisão muda conforme o contexto e não como uma configuração global fixa.
Pronto.
O ponto inteligente é que isso não é gerenciado manualmente caso a caso — é imposto de forma estrutural, de modo que o mesmo protocolo subjacente pode atender a uma transação totalmente privada e a uma totalmente auditável sem precisar de dois sistemas separados.
Isso importa mais para a Dusk do que importaria para uma cadeia genérica de privacidade. Porque a Dusk mira em mercados regulados
onde ambas as propriedades são exigidas simultaneamente — não como alternativas, mas como requisitos paralelos que precisam coexistir.
Entendendo o que faz isso funcionar
A divulgação seletiva trata de quem vê o quê em cada camada.
O XSC faz a aplicação no nível do contrato desse limite.
A liquidação determinística cuida de tornar o resultado certo, independentemente da visibilidade.
E a divulgação seletiva é basicamente o mecanismo que faz o trabalho pesado por trás de tudo isso.
#dusk $DUSK
É privado e transparente para quem e quando?
A Dusk é uma daquelas blockchains Layer1 com foco em privacidade, em que quanto mais tempo você gasta olhando “por baixo do capô”, mais a moldura privacidade versus transparência começa a parecer desatualizada.
A parte que realmente chamou minha atenção é que a Dusk não trata isso como um dilema de troca.
Aqui vai a sequência.
A maioria dos sistemas escolhe um lado.
Totalmente privado ou totalmente transparente.
A Dusk não força essa escolha.
A privacidade se aplica onde é necessária.
A transparência se aplica onde é útil.
A decisão muda conforme o contexto e não como uma configuração global fixa.
Pronto.
O ponto inteligente é que isso não é gerenciado manualmente caso a caso — é imposto de forma estrutural, de modo que o mesmo protocolo subjacente pode atender a uma transação totalmente privada e a uma totalmente auditável sem precisar de dois sistemas separados.
Isso importa mais para a Dusk do que importaria para uma cadeia genérica de privacidade. Porque a Dusk mira em mercados regulados
onde ambas as propriedades são exigidas simultaneamente — não como alternativas, mas como requisitos paralelos que precisam coexistir.
Entendendo o que faz isso funcionar
A divulgação seletiva trata de quem vê o quê em cada camada.
O XSC faz a aplicação no nível do contrato desse limite.
A liquidação determinística cuida de tornar o resultado certo, independentemente da visibilidade.
E a divulgação seletiva é basicamente o mecanismo que faz o trabalho pesado por trás de tudo isso.
#dusk $DUSK
@Dusk As instituições não tomam decisões da noite para o dia, e isso é especialmente verdade quando se trata de algo tão decisivo quanto a adoção de blockchain em um ambiente de bolsa regulada.
Mas uma tendência mais ampla tornou-se bastante clara nos últimos anos: as bolsas reguladas estão, gradualmente, migrando para infraestruturas de blockchain principalmente porque a velocidade de liquidação e a transparência operacional são, objetivamente, melhores do que aquilo que a maioria dos sistemas legados historicamente ofereceu aos participantes do mercado.
Essa mudança costuma ocorrer em etapas cuidadosas e deliberadas, como a maior parte das transformações significativas em indústrias reguladas: primeiro, testes internos extensivos; depois, programas-piloto limitados com participantes selecionados; e, em seguida, escalonamento gradual quando os resultados iniciais se sustentam sob condições operacionais reais e sob escrutínio regulatório.
A Dusk está posicionada como parte desse movimento mais amplo da indústria, oferecendo às instituições uma camada base especificamente desenhada para atender às suas obrigações regulatórias existentes, sem forçá-las a abandonar as estruturas de conformidade e os processos internos que já investiram pesadamente para construir ao longo de muitos anos.
Esse último ponto importa enormemente na prática: as instituições não buscam reinventar todo o seu aparato de conformidade apenas para experimentar uma tecnologia nova; elas procuram uma infraestrutura que possa se encaixar no que já funciona para elas enquanto melhora de verdade as partes que precisam de aprimoramento.
#dusk $DUSK
Mas uma tendência mais ampla tornou-se bastante clara nos últimos anos: as bolsas reguladas estão, gradualmente, migrando para infraestruturas de blockchain principalmente porque a velocidade de liquidação e a transparência operacional são, objetivamente, melhores do que aquilo que a maioria dos sistemas legados historicamente ofereceu aos participantes do mercado.
Essa mudança costuma ocorrer em etapas cuidadosas e deliberadas, como a maior parte das transformações significativas em indústrias reguladas: primeiro, testes internos extensivos; depois, programas-piloto limitados com participantes selecionados; e, em seguida, escalonamento gradual quando os resultados iniciais se sustentam sob condições operacionais reais e sob escrutínio regulatório.
A Dusk está posicionada como parte desse movimento mais amplo da indústria, oferecendo às instituições uma camada base especificamente desenhada para atender às suas obrigações regulatórias existentes, sem forçá-las a abandonar as estruturas de conformidade e os processos internos que já investiram pesadamente para construir ao longo de muitos anos.
Esse último ponto importa enormemente na prática: as instituições não buscam reinventar todo o seu aparato de conformidade apenas para experimentar uma tecnologia nova; elas procuram uma infraestrutura que possa se encaixar no que já funciona para elas enquanto melhora de verdade as partes que precisam de aprimoramento.
#dusk $DUSK
@Dusk Já se perguntou como um contrato inteligente pode ser confidencial quando blockchains são construídas com a ideia de transparência?
Essa pergunta é basicamente o que o padrão XSC responde. A Dusk o impulsiona e a ideia é simples, mas poderosa: a lógica do contrato permanece verificável, então qualquer pessoa pode confirmar que as regras estão sendo seguidas, mas os dados que fluem por essa lógica permanecem privados.
Para valores mobiliários regulamentados, esse é exatamente o equilíbrio de que você precisa. As finanças tradicionais exigem transparência para auditorias, mas também exigem proteção de dados para os clientes.
Historicamente, esses dois requisitos puxaram em direções opostas. O padrão Confidential Security Contract (Contrato de Segurança Confidencial) coloca ambos em uma única estrutura, sem obrigar qualquer lado a ser comprometido.
É um pequeno detalhe técnico com uma implicação real significativa para mercados regulamentados.
#dusk $DUSK
Essa pergunta é basicamente o que o padrão XSC responde. A Dusk o impulsiona e a ideia é simples, mas poderosa: a lógica do contrato permanece verificável, então qualquer pessoa pode confirmar que as regras estão sendo seguidas, mas os dados que fluem por essa lógica permanecem privados.
Para valores mobiliários regulamentados, esse é exatamente o equilíbrio de que você precisa. As finanças tradicionais exigem transparência para auditorias, mas também exigem proteção de dados para os clientes.
Historicamente, esses dois requisitos puxaram em direções opostas. O padrão Confidential Security Contract (Contrato de Segurança Confidencial) coloca ambos em uma única estrutura, sem obrigar qualquer lado a ser comprometido.
É um pequeno detalhe técnico com uma implicação real significativa para mercados regulamentados.
#dusk $DUSK
@BabylonLabs_io Algo sobre a estrutura do conjunto “Universal Challenger” pareceu contraintuitivo quando, de fato, sentei para analisar direito.
A documentação deixa claro que este conjunto não foi planejado para se abrir à participação sem permissão; a restrição faz parte do próprio design, não uma limitação temporária que será afrouxada à medida que amadurecer.
Eu inicialmente supus que esse era o caminho usual da maioria dos sistemas: começa com um grupo restrito, constrói confiança com o tempo e depois vai abrindo a participação gradualmente à medida que a rede cresce e a confiança se acumula naturalmente.
Mas este modelo não foi estruturado dessa forma. Novos Universal Challengers entram especificamente via governança, adicionando operadores verificados ao registro, e não por alguém que ingresse de forma independente depois de construir reputação em outros lugares, não importa há quanto tempo tenha participado do ecossistema mais amplo.
A distinção interessante não é apenas “fechado hoje versus aberto amanhã”, como se isso fosse apenas um recorte de um estágio inicial. A questão é se a abertura alguma vez fez parte da arquitetura. Aqui, o modelo de confiança é construído em torno de um conjunto de challengers curado e deliberadamente limitado, com expansão acontecendo apenas por meio de governança—não por entrada sem permissão—uma escolha, não uma fase.
#baby
$BABY
A documentação deixa claro que este conjunto não foi planejado para se abrir à participação sem permissão; a restrição faz parte do próprio design, não uma limitação temporária que será afrouxada à medida que amadurecer.
Eu inicialmente supus que esse era o caminho usual da maioria dos sistemas: começa com um grupo restrito, constrói confiança com o tempo e depois vai abrindo a participação gradualmente à medida que a rede cresce e a confiança se acumula naturalmente.
Mas este modelo não foi estruturado dessa forma. Novos Universal Challengers entram especificamente via governança, adicionando operadores verificados ao registro, e não por alguém que ingresse de forma independente depois de construir reputação em outros lugares, não importa há quanto tempo tenha participado do ecossistema mais amplo.
A distinção interessante não é apenas “fechado hoje versus aberto amanhã”, como se isso fosse apenas um recorte de um estágio inicial. A questão é se a abertura alguma vez fez parte da arquitetura. Aqui, o modelo de confiança é construído em torno de um conjunto de challengers curado e deliberadamente limitado, com expansão acontecendo apenas por meio de governança—não por entrada sem permissão—uma escolha, não uma fase.
#baby
$BABY
@BabylonLabs_io Esse é o número ao qual eu continuo voltando. O campo OP_RETURN do Bitcoin atinge o limite de 80 bytes.
Não 800. Não 8.000. Oitenta.
a documentação diz que um checkpoint bruto do Babylon é maior do que esse limite. Ele contém múltiplas partes dos dados de epoch, um hash de commit, um bitmap de assinatura e a assinatura agregada. Os dados completos do checkpoint não cabem dentro de um único campo OP RETURN.
Então ele se divide. Duas transações do Bitcoin em vez de uma, a cada checkpoint, para sempre.
Eu continuo ficando apenas com o número em si, separado do mecanismo que ele impõe. Oitenta bytes é pequeno o suficiente para que quase qualquer coisa significativa transborde. Ele não foi dimensionado para checkpoints ou provas, ou qualquer coisa que o Babylon especificamente precise. O limite do OP_RETURN do próprio Bitcoin existe para manter dados arbitrários na cadeia pequenos o bastante para desencorajar abusos de um tipo de saída que foi pensado apenas para carregar um pouco.
O Babylon não recebeu 80 bytes porque 80 era generoso o bastante para o que precisava fazer. Ele recebeu 80 porque é simplesmente o que já estava lá, definido anos antes, innegociável no momento em que o Babylon apareceu precisando de espaço dentro dele.
A restrição do OP RETURN do Bitcoin é uma regra com a qual o Babylon precisa trabalhar, não um parâmetro que ele possa reescrever. A divisão do checkpoint existe porque os dados têm que caber dentro de um limite que foi definido muito antes de o Babylon precisar dele. Não é um arranjo temporário esperando uma solução mais limpa; é o resultado prático de construir em torno de uma regra fixa do Bitcoin.
#baby $BABY
Não 800. Não 8.000. Oitenta.
a documentação diz que um checkpoint bruto do Babylon é maior do que esse limite. Ele contém múltiplas partes dos dados de epoch, um hash de commit, um bitmap de assinatura e a assinatura agregada. Os dados completos do checkpoint não cabem dentro de um único campo OP RETURN.
Então ele se divide. Duas transações do Bitcoin em vez de uma, a cada checkpoint, para sempre.
Eu continuo ficando apenas com o número em si, separado do mecanismo que ele impõe. Oitenta bytes é pequeno o suficiente para que quase qualquer coisa significativa transborde. Ele não foi dimensionado para checkpoints ou provas, ou qualquer coisa que o Babylon especificamente precise. O limite do OP_RETURN do próprio Bitcoin existe para manter dados arbitrários na cadeia pequenos o bastante para desencorajar abusos de um tipo de saída que foi pensado apenas para carregar um pouco.
O Babylon não recebeu 80 bytes porque 80 era generoso o bastante para o que precisava fazer. Ele recebeu 80 porque é simplesmente o que já estava lá, definido anos antes, innegociável no momento em que o Babylon apareceu precisando de espaço dentro dele.
A restrição do OP RETURN do Bitcoin é uma regra com a qual o Babylon precisa trabalhar, não um parâmetro que ele possa reescrever. A divisão do checkpoint existe porque os dados têm que caber dentro de um limite que foi definido muito antes de o Babylon precisar dele. Não é um arranjo temporário esperando uma solução mais limpa; é o resultado prático de construir em torno de uma regra fixa do Bitcoin.
#baby $BABY
VICUSDT está em alta +47,1% hoje.
Qual é o seu próximo movimento?
Vote e explique sua estratégia nos comentários.
#writetoearn #CryptoNewss #BinanceSquareFamily
$PLTR
$VIC
$BTW
Qual é o seu próximo movimento?
Vote e explique sua estratégia nos comentários.
#writetoearn #CryptoNewss #BinanceSquareFamily
$PLTR
$VIC
$BTW
🟩Buy now
0%
🟦Wait for a pullback
0%
🟨Take profits
0%
🟪Stay away
0%
0 Votos • Votação encerrada
@BabylonLabs_io Quase não me dei ao trabalho de ler as entrelinhas sobre rehypothecation (rehipoteca) na documentação do Trustless Bitcoin Vaults (TBV) hoje — achei que seria a mesma linguagem vaga, "não fazemos isso", que praticamente todo protocolo usa.
Não era vaga. A frase exata era "cannot be rehypothecated" (não pode ser rehipotecado) e alguma coisa nesse enunciado específico fez eu parar de rolar.
Eu já tinha visto colapsos em DeFi construídos exatamente nesse modelo: um colateral supostamente quieto é reaproveitado nos bastidores e acaba contado mais de uma vez, até a música parar e todo mundo perceber que o mesmo Bitcoin estava dando lastro para mais de uma promessa ao mesmo tempo. Essa palavra — rehypothecation — tem destruído pessoas de forma bem real.
Então eu fui atrás do mecanismo real por trás da alegação, não apenas da frase. O que encontrei: não existe caminho no protocolo para BTC travado ir para qualquer lugar, exceto para a única posição que ele já está respaldando. Não é uma escolha de política que alguém poderia reverter mais tarde, às escondidas. É um fato estrutural de como o cofre (vault) é construído.
Essa diferença mudou totalmente a forma como eu li o resto da página depois disso. Uma promessa pode se curvar sob pressão. Uma impossibilidade estrutural não pode — simplesmente não existe outro lugar para o BTC ir, não importa o que alguém a montante decida fazer.
Eu entrei esperando aquela ladainha padrão. Saí acreditando naquela frase específica mais do que eu esperava ao entrar.
#baby $BABY
Não era vaga. A frase exata era "cannot be rehypothecated" (não pode ser rehipotecado) e alguma coisa nesse enunciado específico fez eu parar de rolar.
Eu já tinha visto colapsos em DeFi construídos exatamente nesse modelo: um colateral supostamente quieto é reaproveitado nos bastidores e acaba contado mais de uma vez, até a música parar e todo mundo perceber que o mesmo Bitcoin estava dando lastro para mais de uma promessa ao mesmo tempo. Essa palavra — rehypothecation — tem destruído pessoas de forma bem real.
Então eu fui atrás do mecanismo real por trás da alegação, não apenas da frase. O que encontrei: não existe caminho no protocolo para BTC travado ir para qualquer lugar, exceto para a única posição que ele já está respaldando. Não é uma escolha de política que alguém poderia reverter mais tarde, às escondidas. É um fato estrutural de como o cofre (vault) é construído.
Essa diferença mudou totalmente a forma como eu li o resto da página depois disso. Uma promessa pode se curvar sob pressão. Uma impossibilidade estrutural não pode — simplesmente não existe outro lugar para o BTC ir, não importa o que alguém a montante decida fazer.
Eu entrei esperando aquela ladainha padrão. Saí acreditando naquela frase específica mais do que eu esperava ao entrar.
#baby $BABY
@BabylonLabs_io De acordo com o repositório de documentação o vaultBTC funciona como um token contábil interno, não como algo que negocia, faz transferências ou possui um mercado secundário próprio.
Essa distinção passou a importar ainda mais quando eu realmente me sentei com ela. Em quase todos os sistemas DeFi, um token de representação é a ideia central — é a coisa que circula, que é negociada, que constrói liquidez em outros lugares. O vaultBTC nos Trustless Bitcoin Vaults (TBV) não faz nada disso. Ele existe puramente para acompanhar o estado dentro de uma integração específica.
Ele só se move entre componentes internos próprios do protocolo, nunca para mercados abertos, nunca como um ativo livremente negociável sobre o qual alguém poderia especular.
Essa é uma restrição deliberada, não uma funcionalidade ausente. Um token projetado para nunca sair do seu próprio sistema de contabilidade elimina uma categoria inteira de risco que surge com tokens que as pessoas de fato negociam.
Um token que deliberadamente não pode circular muda a forma como você pensa sobre o que risco significa para ele?
#baby $BABY
Essa distinção passou a importar ainda mais quando eu realmente me sentei com ela. Em quase todos os sistemas DeFi, um token de representação é a ideia central — é a coisa que circula, que é negociada, que constrói liquidez em outros lugares. O vaultBTC nos Trustless Bitcoin Vaults (TBV) não faz nada disso. Ele existe puramente para acompanhar o estado dentro de uma integração específica.
Ele só se move entre componentes internos próprios do protocolo, nunca para mercados abertos, nunca como um ativo livremente negociável sobre o qual alguém poderia especular.
Essa é uma restrição deliberada, não uma funcionalidade ausente. Um token projetado para nunca sair do seu próprio sistema de contabilidade elimina uma categoria inteira de risco que surge com tokens que as pessoas de fato negociam.
Um token que deliberadamente não pode circular muda a forma como você pensa sobre o que risco significa para ele?
#baby $BABY
Verificado
@BabylonLabs_io De acordo com a documentação, se um cofre expirar porque a configuração off-chain falhou antes de concluir dentro da janela de ativação, o peg na taxa também é reembolsado.
Esse detalhe específico mudou a forma como eu li a estrutura de taxas aqui. Eu tinha assumido que um peg na taxa era simplesmente o custo de tentar a ativação, reembolsável ou não, dependendo do resultado, do jeito que a maioria das taxas de entrada funciona em outros lugares.
Não é assim. A taxa está vinculada especificamente à ativação bem-sucedida, e não à tentativa em si. Uma configuração malsucedida sem culpa das ações do depositante não os deixa pagando por algo que na verdade nunca aconteceu.
O que eu não tinha considerado é que isso cobre apenas a taxa, não o tempo gasto esperando uma configuração que travou. São custos realmente diferentes e apenas um deles tem um caminho documentado para recuperação.
Um reembolso de taxa como esse muda a quantidade de risco que você associaria a uma ativação falha, ou o tempo perdido importa mais para você de qualquer forma?
#baby $BABY
Esse detalhe específico mudou a forma como eu li a estrutura de taxas aqui. Eu tinha assumido que um peg na taxa era simplesmente o custo de tentar a ativação, reembolsável ou não, dependendo do resultado, do jeito que a maioria das taxas de entrada funciona em outros lugares.
Não é assim. A taxa está vinculada especificamente à ativação bem-sucedida, e não à tentativa em si. Uma configuração malsucedida sem culpa das ações do depositante não os deixa pagando por algo que na verdade nunca aconteceu.
O que eu não tinha considerado é que isso cobre apenas a taxa, não o tempo gasto esperando uma configuração que travou. São custos realmente diferentes e apenas um deles tem um caminho documentado para recuperação.
Um reembolso de taxa como esse muda a quantidade de risco que você associaria a uma ativação falha, ou o tempo perdido importa mais para você de qualquer forma?
#baby $BABY
@BabylonLabs_io De acordo com a documentação sobre o modelo de confiança dos Trustless Bitcoin Vaults (TBV), a confiança residual que não é totalmente eliminada se divide em duas categorias: governança e resposta a emergências, multi sigs.
Eu vinha tratando “trustless” como algo próximo do absoluto antes de ler este enquadramento de forma tão específica. Não é. É “trustless” para o mecanismo do dia a dia, com duas exceções estreitas e nomeadas por trás dele.
Multi sigs de governança lidam com mudanças de parâmetros no nível de protocolo — o tipo de decisões que precisa de alguma autoridade coordenada para existir. Multi sigs de resposta a emergências são o plano de contingência para cenários genuinamente catastróficos, no domínio específico do Conselho de Segurança.
O que acho relevante é valer a pena considerar explicitamente essas duas categorias: isso é mais honesto do que a maioria dos sistemas que silenciosamente têm pontos semelhantes de confiança residual, mas sem nunca rotulá-los.
Nomear claramente as exceções faz com que a afirmação geral de “trustless” pareça mais forte para você, ou apenas desloca para outro lugar onde a desconfiança deveria estar?
#baby $BABY
Eu vinha tratando “trustless” como algo próximo do absoluto antes de ler este enquadramento de forma tão específica. Não é. É “trustless” para o mecanismo do dia a dia, com duas exceções estreitas e nomeadas por trás dele.
Multi sigs de governança lidam com mudanças de parâmetros no nível de protocolo — o tipo de decisões que precisa de alguma autoridade coordenada para existir. Multi sigs de resposta a emergências são o plano de contingência para cenários genuinamente catastróficos, no domínio específico do Conselho de Segurança.
O que acho relevante é valer a pena considerar explicitamente essas duas categorias: isso é mais honesto do que a maioria dos sistemas que silenciosamente têm pontos semelhantes de confiança residual, mas sem nunca rotulá-los.
Nomear claramente as exceções faz com que a afirmação geral de “trustless” pareça mais forte para você, ou apenas desloca para outro lugar onde a desconfiança deveria estar?
#baby $BABY
@BabylonLabs_io Per materiais próprios da Babylon, as funções centrais do BABY se resumem a três coisas: governança e segurança do gás — o token que alimenta as transações define parâmetros e sustenta a camada de staking da rede — tudo em um só.
Eu estava mentalmente arquivando isso sob um título genérico de utilidade, sem separá-las corretamente. Elas são, de fato, trabalhos diferentes.
Gás é a função de taxa paga pelas transações na rede. Governança é a função de votação que decide o que o protocolo fará de fato em seguida. Segurança é a função de staking: o BABY é bloqueado e fica em risco para ajudar a proteger a cadeia, na mesma camada econômica mais ampla em que o Trustless Bitcoin Vaults (TBV) está ao lado.
Um detentor que faz staking apenas para obter rendimento de segurança tem uma relação diferente com o BABY do que alguém que paga gás ou alguém que vota em propostas. Mesmo token. Três exposições separadas, três razões separadas pelas quais alguém pode estar, de fato, mantendo-o.
Não encontrei uma análise de quanto da atividade atual se enquadra em cada categoria em relação às outras.
#baby $BABY
Eu estava mentalmente arquivando isso sob um título genérico de utilidade, sem separá-las corretamente. Elas são, de fato, trabalhos diferentes.
Gás é a função de taxa paga pelas transações na rede. Governança é a função de votação que decide o que o protocolo fará de fato em seguida. Segurança é a função de staking: o BABY é bloqueado e fica em risco para ajudar a proteger a cadeia, na mesma camada econômica mais ampla em que o Trustless Bitcoin Vaults (TBV) está ao lado.
Um detentor que faz staking apenas para obter rendimento de segurança tem uma relação diferente com o BABY do que alguém que paga gás ou alguém que vota em propostas. Mesmo token. Três exposições separadas, três razões separadas pelas quais alguém pode estar, de fato, mantendo-o.
Não encontrei uma análise de quanto da atividade atual se enquadra em cada categoria em relação às outras.
#baby $BABY
Verificado
@BabylonLabs_io Consulte a própria documentação de integração da carteira da Babylon se um detentor de BABY não tomar nenhuma ação sobre uma proposta; seu poder de voto será automaticamente delegado ao seu validador.
As decisões tomadas aqui repercutem também no ambiente dos Trustless Bitcoin Vaults (TBV). Então o que "não votar" significa não é um detalhe secundário.
Não votar não significa permanecer neutro. Outra pessoa faz um voto em seu nome. Com base no julgamento dela. Não no seu.
Um detentor que discorda do seu validador, mas nunca chega a votar, não protege sua posição ficando em silêncio. O silêncio entrega a decisão à discrição de outra pessoa.
Este é o padrão de democracia líquida padrão em cadeias Cosmos, projetado para manter o quórum alcançável.
Aqui está a parte que torna isso ainda mais preciso. Um detentor pode substituir o voto padrão do seu validador, mas apenas votando antes do período terminar. Em uma proposta urgente com apenas uma janela de um dia, essa chance de substituição pode expirar antes que alguém verificando ocasionalmente sequer perceba.
Uma janela de substituição menor mudaria o quanto você levaria a sério a verificação?
#baby $BABY
As decisões tomadas aqui repercutem também no ambiente dos Trustless Bitcoin Vaults (TBV). Então o que "não votar" significa não é um detalhe secundário.
Não votar não significa permanecer neutro. Outra pessoa faz um voto em seu nome. Com base no julgamento dela. Não no seu.
Um detentor que discorda do seu validador, mas nunca chega a votar, não protege sua posição ficando em silêncio. O silêncio entrega a decisão à discrição de outra pessoa.
Este é o padrão de democracia líquida padrão em cadeias Cosmos, projetado para manter o quórum alcançável.
Aqui está a parte que torna isso ainda mais preciso. Um detentor pode substituir o voto padrão do seu validador, mas apenas votando antes do período terminar. Em uma proposta urgente com apenas uma janela de um dia, essa chance de substituição pode expirar antes que alguém verificando ocasionalmente sequer perceba.
Uma janela de substituição menor mudaria o quanto você levaria a sério a verificação?
#baby $BABY
Parcialmente verdadeiro
@BabylonLabs_io Per a documentação da própria Babylon, o mecanismo de pagamento de “fairness” (justiça) dos Trustless Bitcoin Vaults (TBV) durante a liquidação oferece dois caminhos distintos de liquidação, e eu queria entender o que determina qual deles se aplica, em vez de tratá-los como um processo único e indiferenciado.
O primeiro caminho é o reembolso direto da dívida: o liquidante paga o que o devedor deve e isso satisfaz a posição. O segundo caminho paga o liquidante em WBTC.
Eu voltei e encontrei, de fato, a lógica de gatilho que eu tinha perdido da primeira vez que olhei. Pela documentação, isso se resume a liquidação parcial versus liquidação total. No caso comum, numa liquidação parcial, qualquer excedente é devolvido como pagamento adicional da dívida.
Em uma liquidação total, especificamente, uma vez que toda a dívida em aberto já está coberta pela própria liquidação, é o WBTC que é usado para o restante do acerto.
Isso realmente resolveu a pergunta em aberto que parecia haver para mim antes. Não são dois caminhos arbitrários escolhidos de forma imprevisível; é uma divisão bastante clara baseada em se a dívida ainda precisa ser coberta ou se já foi totalmente considerada quando a liquidação é concluída.
O que eu não tinha considerado antes é que isso significa que a maioria das liquidações é parcial, e não total; portanto, provavelmente é resolvida por um simples reembolso da dívida, com o WBTC como caso de exceção em vez de uma alternativa igualmente comum. Sabendo que a lógica de gatilho é tão sistemática, quanto peso você colocaria na noção de fairness como uma alegação aqui?
#baby $BABY
O primeiro caminho é o reembolso direto da dívida: o liquidante paga o que o devedor deve e isso satisfaz a posição. O segundo caminho paga o liquidante em WBTC.
Eu voltei e encontrei, de fato, a lógica de gatilho que eu tinha perdido da primeira vez que olhei. Pela documentação, isso se resume a liquidação parcial versus liquidação total. No caso comum, numa liquidação parcial, qualquer excedente é devolvido como pagamento adicional da dívida.
Em uma liquidação total, especificamente, uma vez que toda a dívida em aberto já está coberta pela própria liquidação, é o WBTC que é usado para o restante do acerto.
Isso realmente resolveu a pergunta em aberto que parecia haver para mim antes. Não são dois caminhos arbitrários escolhidos de forma imprevisível; é uma divisão bastante clara baseada em se a dívida ainda precisa ser coberta ou se já foi totalmente considerada quando a liquidação é concluída.
O que eu não tinha considerado antes é que isso significa que a maioria das liquidações é parcial, e não total; portanto, provavelmente é resolvida por um simples reembolso da dívida, com o WBTC como caso de exceção em vez de uma alternativa igualmente comum. Sabendo que a lógica de gatilho é tão sistemática, quanto peso você colocaria na noção de fairness como uma alegação aqui?
#baby $BABY
Verificado
@BabylonLabs_io Trustless é o benefício que continuo testando em diferentes partes de como os Trustless Bitcoin Vaults (TBV) realmente se observam, e a parte que eu examinei hoje vem diretamente da própria documentação da Babylon sobre o Vigilante Checkpointing Monitor — um processo em segundo plano em que provavelmente a maioria das pessoas nem pensa.
De acordo com essa documentação, o monitor verifica continuamente duas coisas separadas. Primeiro, se o registro interno da Babylon da cadeia de Bitcoin realmente corresponde ao que está de fato no Bitcoin — uma verificação de consistência. Segundo, se dados válidos de checkpoint estão sendo reportados de forma oportuna — descrito na documentação como uma verificação de vivacidade (liveness), distinta de apenas checar a correção.
Essa segunda verificação importa porque um sistema pode tecnicamente ter dados corretos enquanto ainda falha com você por causa de atraso. Se algo verdadeiro for retido por tempo suficiente, ele funciona quase da mesma forma como se estivesse totalmente oculto.
Vou ser honesto: um monitor como esse, conforme documentado, encontra problemas depois que eles começam, não antes. É detecção, não prevenção; e a detecção só funciona se ele estiver realmente rodando e alguém estiver prestando atenção quando ele sinaliza algo.
Trustless não significa que nada pode dar errado. Pela forma como a Babylon enquadra, isso significa que, quando algo dá errado, existe um caminho documentado para que isso se torne visível. Saber que existe um monitoramento ativo e documentado por trás de um sistema muda o quanto de verificação independente você ainda gostaria de fazer por conta própria?
#baby $BABY
De acordo com essa documentação, o monitor verifica continuamente duas coisas separadas. Primeiro, se o registro interno da Babylon da cadeia de Bitcoin realmente corresponde ao que está de fato no Bitcoin — uma verificação de consistência. Segundo, se dados válidos de checkpoint estão sendo reportados de forma oportuna — descrito na documentação como uma verificação de vivacidade (liveness), distinta de apenas checar a correção.
Essa segunda verificação importa porque um sistema pode tecnicamente ter dados corretos enquanto ainda falha com você por causa de atraso. Se algo verdadeiro for retido por tempo suficiente, ele funciona quase da mesma forma como se estivesse totalmente oculto.
Vou ser honesto: um monitor como esse, conforme documentado, encontra problemas depois que eles começam, não antes. É detecção, não prevenção; e a detecção só funciona se ele estiver realmente rodando e alguém estiver prestando atenção quando ele sinaliza algo.
Trustless não significa que nada pode dar errado. Pela forma como a Babylon enquadra, isso significa que, quando algo dá errado, existe um caminho documentado para que isso se torne visível. Saber que existe um monitoramento ativo e documentado por trás de um sistema muda o quanto de verificação independente você ainda gostaria de fazer por conta própria?
#baby $BABY
@BabylonLabs_io A autocustódia é o benefício ao qual eu continuo voltando quando penso no que na verdade os Cofres de Bitcoin Sem Confiança (TBV) estão oferecendo: suas chaves, seu Bitcoin o tempo todo, sem exceção, em algum lugar escondido nas letras miúdas.
O que me faz confiar nessa afirmação, em vez de apenas aceitar, é entender um pouco do que realmente está acontecendo por baixo dela, com base em como a própria documentação da Babylon descreve o design.
O Bitcoin que dá lastro a uma posição permanece na própria rede Bitcoin durante todo o processo: nunca é entregue a um custodiante, nunca é pooled/compartilhado com as finanças de outras pessoas e nunca é embrulhado em uma representação separada em outra cadeia.
As regras que determinam quando e como ele pode se mover são pré-assinadas e impostas por meio de provas criptográficas, em vez de depender da discricionariedade de uma parte.
Essa diferença importa enormemente para mim. Não é que um terceiro esteja aí, confiável, para se comportar de forma honesta. É que as condições de gasto foram fixadas criptograficamente desde o início.
Vou dizer isso com honestidade: a autocustódia protege o Bitcoin de um custodiante. Mas não protege ninguém de perder as próprias chaves, nem de bugs em um software que ainda está rotulado como beta. Esses são riscos diferentes, e eu não acho que o enquadramento dos quatro benefícios sempre deixe essa distinção clara o suficiente.
A rede de testes pública já está no ar, agora, se você quiser ver isso acontecer por conta própria. Saber o mecanismo exato mudaria o quanto você se sentiria confortável com a alegação de autocustódia, ou o resultado importa mais para você do que o como?
#baby $BABY
O que me faz confiar nessa afirmação, em vez de apenas aceitar, é entender um pouco do que realmente está acontecendo por baixo dela, com base em como a própria documentação da Babylon descreve o design.
O Bitcoin que dá lastro a uma posição permanece na própria rede Bitcoin durante todo o processo: nunca é entregue a um custodiante, nunca é pooled/compartilhado com as finanças de outras pessoas e nunca é embrulhado em uma representação separada em outra cadeia.
As regras que determinam quando e como ele pode se mover são pré-assinadas e impostas por meio de provas criptográficas, em vez de depender da discricionariedade de uma parte.
Essa diferença importa enormemente para mim. Não é que um terceiro esteja aí, confiável, para se comportar de forma honesta. É que as condições de gasto foram fixadas criptograficamente desde o início.
Vou dizer isso com honestidade: a autocustódia protege o Bitcoin de um custodiante. Mas não protege ninguém de perder as próprias chaves, nem de bugs em um software que ainda está rotulado como beta. Esses são riscos diferentes, e eu não acho que o enquadramento dos quatro benefícios sempre deixe essa distinção clara o suficiente.
A rede de testes pública já está no ar, agora, se você quiser ver isso acontecer por conta própria. Saber o mecanismo exato mudaria o quanto você se sentiria confortável com a alegação de autocustódia, ou o resultado importa mais para você do que o como?
#baby $BABY
@BabylonLabs_io Há um detalhe na forma como os Trustless Bitcoin Vaults (TBV) lidam com a liquidação do acerto que achei genuinamente bem pensado no mecanismo de pagamento de “fairness”.
Quando uma posição é liquidada, existem duas coisas diferentes que podem acontecer para fazer o credor ficar “inteiro”: ou a dívida em aberto do mutuário é quitada diretamente, ou o liquidante recebe um pagamento em uma representação de Bitcoin “embrulhado” (wrapped) em vez disso. Qual caminho de fato se aplica depende das circunstâncias específicas da liquidação.
O que se destacou para mim foi a palavra “fairness” associada a esse mecanismo especificamente. Isso sugere que a estrutura de pagamento foi desenhada com o objetivo de garantir que nem o depositante nem o liquidante acabem com uma vantagem injusta apenas por causa de qual rota de liquidação ocorreu no caso deles. Uma liquidação que se resolve por meio de quitação direta da dívida não deveria deixar alguém significativamente pior do que uma que se resolve via pagamento em WBTC, mantendo-se tudo o mais igual.
Eu acho esse nível de atenção genuinamente tranquilizador, honestamente. As mecânicas de liquidação são um dos lugares onde pequenos descuidos de design tendem a gerar uma injustiça real, quantificável, para alguém — e está claro que esse detalhe específico foi pensado, em vez de ser deixado como uma “ideia posterior” depois que o fluxo principal já estava desenhado.
A testnet pública está no ar se você quiser ver como esse mecanismo de fairness realmente acontece em um cenário simulado de liquidação.
#baby $BABY
Quando uma posição é liquidada, existem duas coisas diferentes que podem acontecer para fazer o credor ficar “inteiro”: ou a dívida em aberto do mutuário é quitada diretamente, ou o liquidante recebe um pagamento em uma representação de Bitcoin “embrulhado” (wrapped) em vez disso. Qual caminho de fato se aplica depende das circunstâncias específicas da liquidação.
O que se destacou para mim foi a palavra “fairness” associada a esse mecanismo especificamente. Isso sugere que a estrutura de pagamento foi desenhada com o objetivo de garantir que nem o depositante nem o liquidante acabem com uma vantagem injusta apenas por causa de qual rota de liquidação ocorreu no caso deles. Uma liquidação que se resolve por meio de quitação direta da dívida não deveria deixar alguém significativamente pior do que uma que se resolve via pagamento em WBTC, mantendo-se tudo o mais igual.
Eu acho esse nível de atenção genuinamente tranquilizador, honestamente. As mecânicas de liquidação são um dos lugares onde pequenos descuidos de design tendem a gerar uma injustiça real, quantificável, para alguém — e está claro que esse detalhe específico foi pensado, em vez de ser deixado como uma “ideia posterior” depois que o fluxo principal já estava desenhado.
A testnet pública está no ar se você quiser ver como esse mecanismo de fairness realmente acontece em um cenário simulado de liquidação.
#baby $BABY
Que moeda você está assistindo hoje?
Vote abaixo e compartilhe o porquê. 👇
$BTW
$APR
#APR #crypto #BinanceSquare #Write2Earn
Vote abaixo e compartilhe o porquê. 👇
$BTW
$APR
#APR #crypto #BinanceSquare #Write2Earn
🔘 APR
0%
🔘 BTW
0%
0 Votos • Votação encerrada
Qual projeto tem o maior potencial a longo prazo? 👇
🗳️ Vote na pesquisa:
$RIF
$DEXE
$RE
🗳️ Vote na pesquisa:
$RIF
$DEXE
$RE
🔹 RIF
71%
🔹 DEXE
29%
🔹 RE
0%
7 Votos • Votação encerrada
Parcialmente verdadeiro
@BabylonLabs_io Há uma distinção nos Cofres de Bitcoin sem Confiança (TBV) que quase passei batida — a diferença entre a camada de protocolo e as aplicações construídas em cima dela.
O TBV em si é o protocolo central de colateral. Ele é responsável pela criação dos vaults, pela redenção dos vaults, pelo fluxo de verificação de provas e pelo estado do vault. Esse é o trabalho inteiro da camada de protocolo — nada mais.
Tudo o resto — empréstimos e, eventualmente, stablecoins — opções e seguros fica por cima, como uma camada separada. Cada aplicação define sua própria lógica de produto, suas próprias regras de empréstimo, suas próprias regras de liquidação e sua própria estrutura de recompensas. A primeira aplicação em funcionamento hoje é o empréstimo nativo lastreado em Bitcoin.
O que considero útil nessa separação é que um vault é criado para uma aplicação específica no momento da criação e não pode ser movido entre aplicações depois.
O protocolo não fica mais complicado conforme mais aplicações se integram a ele. Cada uma se conecta por meio do seu próprio adapter e a lógica central do vault permanece exatamente a mesma por baixo.
É eficiente em capital e usa o BTC nativo diretamente como colateral — sem wrapping, sem bridging. Ambas essas coisas vêm de manter a camada de protocolo tão limitada e deixar que as aplicações cuidem de todo o resto.
A testnet pública já está ativa, caso você queira ver essa estrutura em duas camadas na prática, em vez de apenas ler sobre ela.
#baby $BABY
O TBV em si é o protocolo central de colateral. Ele é responsável pela criação dos vaults, pela redenção dos vaults, pelo fluxo de verificação de provas e pelo estado do vault. Esse é o trabalho inteiro da camada de protocolo — nada mais.
Tudo o resto — empréstimos e, eventualmente, stablecoins — opções e seguros fica por cima, como uma camada separada. Cada aplicação define sua própria lógica de produto, suas próprias regras de empréstimo, suas próprias regras de liquidação e sua própria estrutura de recompensas. A primeira aplicação em funcionamento hoje é o empréstimo nativo lastreado em Bitcoin.
O que considero útil nessa separação é que um vault é criado para uma aplicação específica no momento da criação e não pode ser movido entre aplicações depois.
O protocolo não fica mais complicado conforme mais aplicações se integram a ele. Cada uma se conecta por meio do seu próprio adapter e a lógica central do vault permanece exatamente a mesma por baixo.
É eficiente em capital e usa o BTC nativo diretamente como colateral — sem wrapping, sem bridging. Ambas essas coisas vêm de manter a camada de protocolo tão limitada e deixar que as aplicações cuidem de todo o resto.
A testnet pública já está ativa, caso você queira ver essa estrutura em duas camadas na prática, em vez de apenas ler sobre ela.
#baby $BABY
Faça login para explorar mais conteúdos