HumairaBTC
228 Publicações
HumairaBTC
Denunciar
Bloquear Utilizador
57 A seguir
680 Seguidores
149 Gostaram
Publicações
·
--
#dusk $DUSK @Dusk_Foundation Comecei a pensar sobre algo que raramente questionamos em cripto:
Quando uma transação realmente termina?
Imagine comprar um imóvel.
O corretor te diz:
“Seu pagamento foi concluído.”
Mas depois acrescenta:
“Existe uma pequena chance de o registro de propriedade mudar amanhã.”
Você provavelmente não chamaria isso de liquidado.
Ainda assim, em muitas blockchains, “confirmado” e “final” não são necessariamente a mesma coisa.
Essa diferença chamou minha atenção quando investiguei mais a fundo o DUSK.
O consenso do DUSK é projetado para uma finalização determinística.
Assim que um bloco é ratificado, a transação atinge a finalidade em vez de ficar em um estado em que os usuários precisam continuar esperando por confirmações adicionais para ganharem confiança. O DUSK descreve isso como evitar reorganizações que apareçam para o usuário sob operação normal.
Isso soa como um detalhe técnico.
Para mercados financeiros, eu não acho que seja.
Imagine liquidar uma negociação de títulos, transferir a propriedade de um ativo ou atualizar um registro financeiro.
A pergunta importante não é apenas:
“Quão rapidamente a transação apareceu?”
É:
“Em que ponto exato todos podem tratar esse resultado como liquidado?”
É por isso que a finalização determinística faz mais sentido para mim no contexto do DUSK.
Trata-se menos de fazer uma transação parecer rápida...
e mais de dar ao mercado um ponto claro e definitivo de não retorno.
Porque, nas finanças, a incerteza após a liquidação não é apenas inconveniente.
Ela pode gerar problemas de conciliação, operacionais e com contrapartes.
Então a pergunta que fica para mim é:
Se um mercado financeiro não consegue te dizer claramente quando uma transação é final, isso foi realmente liquidado em primeiro lugar?
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Comecei a pensar sobre algo que raramente questionamos em cripto:
Quando uma transação realmente termina?
Imagine comprar um imóvel.
O corretor te diz:
“Seu pagamento foi concluído.”
Mas depois acrescenta:
“Existe uma pequena chance de o registro de propriedade mudar amanhã.”
Você provavelmente não chamaria isso de liquidado.
Ainda assim, em muitas blockchains, “confirmado” e “final” não são necessariamente a mesma coisa.
Essa diferença chamou minha atenção quando investiguei mais a fundo o DUSK.
O consenso do DUSK é projetado para uma finalização determinística.
Assim que um bloco é ratificado, a transação atinge a finalidade em vez de ficar em um estado em que os usuários precisam continuar esperando por confirmações adicionais para ganharem confiança. O DUSK descreve isso como evitar reorganizações que apareçam para o usuário sob operação normal.
Isso soa como um detalhe técnico.
Para mercados financeiros, eu não acho que seja.
Imagine liquidar uma negociação de títulos, transferir a propriedade de um ativo ou atualizar um registro financeiro.
A pergunta importante não é apenas:
“Quão rapidamente a transação apareceu?”
É:
“Em que ponto exato todos podem tratar esse resultado como liquidado?”
É por isso que a finalização determinística faz mais sentido para mim no contexto do DUSK.
Trata-se menos de fazer uma transação parecer rápida...
e mais de dar ao mercado um ponto claro e definitivo de não retorno.
Porque, nas finanças, a incerteza após a liquidação não é apenas inconveniente.
Ela pode gerar problemas de conciliação, operacionais e com contrapartes.
Então a pergunta que fica para mim é:
Se um mercado financeiro não consegue te dizer claramente quando uma transação é final, isso foi realmente liquidado em primeiro lugar?
#dusk $DUSK @Dusk
Quando uma transação realmente termina?
Imagine comprar um imóvel.
O corretor te diz:
“Seu pagamento foi concluído.”
Mas depois acrescenta:
“Existe uma pequena chance de o registro de propriedade mudar amanhã.”
Você provavelmente não chamaria isso de liquidado.
Ainda assim, em muitas blockchains, “confirmado” e “final” não são necessariamente a mesma coisa.
Essa diferença chamou minha atenção quando investiguei mais a fundo o DUSK.
O consenso do DUSK é projetado para uma finalização determinística.
Assim que um bloco é ratificado, a transação atinge a finalidade em vez de ficar em um estado em que os usuários precisam continuar esperando por confirmações adicionais para ganharem confiança. O DUSK descreve isso como evitar reorganizações que apareçam para o usuário sob operação normal.
Isso soa como um detalhe técnico.
Para mercados financeiros, eu não acho que seja.
Imagine liquidar uma negociação de títulos, transferir a propriedade de um ativo ou atualizar um registro financeiro.
A pergunta importante não é apenas:
“Quão rapidamente a transação apareceu?”
É:
“Em que ponto exato todos podem tratar esse resultado como liquidado?”
É por isso que a finalização determinística faz mais sentido para mim no contexto do DUSK.
Trata-se menos de fazer uma transação parecer rápida...
e mais de dar ao mercado um ponto claro e definitivo de não retorno.
Porque, nas finanças, a incerteza após a liquidação não é apenas inconveniente.
Ela pode gerar problemas de conciliação, operacionais e com contrapartes.
Então a pergunta que fica para mim é:
Se um mercado financeiro não consegue te dizer claramente quando uma transação é final, isso foi realmente liquidado em primeiro lugar?
#dusk $DUSK @Dusk
102
·
--
#dusk $DUSK @Dusk_Foundation Comecei a analisar o que acontece depois que uma transação é executada.
E encontrei um problema que eu não tinha considerado de verdade.
Uma blockchain pode saber que algo aconteceu.
Mas como o resto do sistema financeiro fica sabendo?
Imagine uma bolsa de valores em que uma negociação acontece dentro do prédio, mas ninguém envia uma mensagem ao clearing house.
A negociação existe.
Mas os sistemas ao redor ainda estão esperando.
Foi isso que tornou o sistema de eventos RUES da DUSK interessante para mim.
Os nós da DUSK podem expor eventos para coisas como blocos aceitos, transações incluídas ou executadas e eventos específicos de contratos. Aplicativos externos podem se inscrever nesses eventos via WebSockets em vez de ficar perguntando constantemente para a cadeia:
“Já aconteceu alguma coisa?”
E aqui há um detalhe importante.
A DUSK também suporta dados históricos de eventos por meio de nós de arquivo e consultas GraphQL, incluindo eventos finalizados.
Então isso não é apenas sobre enviar notificações.
Isso cria uma ponte entre o que aconteceu na blockchain e os sistemas que precisam reagir a isso.
Isso importa muito mais para a infraestrutura financeira do que pode parecer.
Porque um mercado tokenizado não é útil se a blockchain for o único sistema que sabe o que aconteceu.
Custodiantes, exchanges, painéis, sistemas de compliance e outras infraestruturas podem precisar reagir ao mesmo evento.
Isso me fez olhar para o RUES de forma diferente.
Não é a transação.
É o sinal que permite que tudo ao redor da transação continue em movimento.
E agora eu estou pensando:
A finança on-chain realmente consegue escalar para a infraestrutura financeira existente se os sistemas fora da cadeia não conseguem reagir de forma confiável ao que acontece dentro dela?
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Comecei a analisar o que acontece depois que uma transação é executada.
E encontrei um problema que eu não tinha considerado de verdade.
Uma blockchain pode saber que algo aconteceu.
Mas como o resto do sistema financeiro fica sabendo?
Imagine uma bolsa de valores em que uma negociação acontece dentro do prédio, mas ninguém envia uma mensagem ao clearing house.
A negociação existe.
Mas os sistemas ao redor ainda estão esperando.
Foi isso que tornou o sistema de eventos RUES da DUSK interessante para mim.
Os nós da DUSK podem expor eventos para coisas como blocos aceitos, transações incluídas ou executadas e eventos específicos de contratos. Aplicativos externos podem se inscrever nesses eventos via WebSockets em vez de ficar perguntando constantemente para a cadeia:
“Já aconteceu alguma coisa?”
E aqui há um detalhe importante.
A DUSK também suporta dados históricos de eventos por meio de nós de arquivo e consultas GraphQL, incluindo eventos finalizados.
Então isso não é apenas sobre enviar notificações.
Isso cria uma ponte entre o que aconteceu na blockchain e os sistemas que precisam reagir a isso.
Isso importa muito mais para a infraestrutura financeira do que pode parecer.
Porque um mercado tokenizado não é útil se a blockchain for o único sistema que sabe o que aconteceu.
Custodiantes, exchanges, painéis, sistemas de compliance e outras infraestruturas podem precisar reagir ao mesmo evento.
Isso me fez olhar para o RUES de forma diferente.
Não é a transação.
É o sinal que permite que tudo ao redor da transação continue em movimento.
E agora eu estou pensando:
A finança on-chain realmente consegue escalar para a infraestrutura financeira existente se os sistemas fora da cadeia não conseguem reagir de forma confiável ao que acontece dentro dela?
#dusk $DUSK @Dusk
E encontrei um problema que eu não tinha considerado de verdade.
Uma blockchain pode saber que algo aconteceu.
Mas como o resto do sistema financeiro fica sabendo?
Imagine uma bolsa de valores em que uma negociação acontece dentro do prédio, mas ninguém envia uma mensagem ao clearing house.
A negociação existe.
Mas os sistemas ao redor ainda estão esperando.
Foi isso que tornou o sistema de eventos RUES da DUSK interessante para mim.
Os nós da DUSK podem expor eventos para coisas como blocos aceitos, transações incluídas ou executadas e eventos específicos de contratos. Aplicativos externos podem se inscrever nesses eventos via WebSockets em vez de ficar perguntando constantemente para a cadeia:
“Já aconteceu alguma coisa?”
E aqui há um detalhe importante.
A DUSK também suporta dados históricos de eventos por meio de nós de arquivo e consultas GraphQL, incluindo eventos finalizados.
Então isso não é apenas sobre enviar notificações.
Isso cria uma ponte entre o que aconteceu na blockchain e os sistemas que precisam reagir a isso.
Isso importa muito mais para a infraestrutura financeira do que pode parecer.
Porque um mercado tokenizado não é útil se a blockchain for o único sistema que sabe o que aconteceu.
Custodiantes, exchanges, painéis, sistemas de compliance e outras infraestruturas podem precisar reagir ao mesmo evento.
Isso me fez olhar para o RUES de forma diferente.
Não é a transação.
É o sinal que permite que tudo ao redor da transação continue em movimento.
E agora eu estou pensando:
A finança on-chain realmente consegue escalar para a infraestrutura financeira existente se os sistemas fora da cadeia não conseguem reagir de forma confiável ao que acontece dentro dela?
#dusk $DUSK @Dusk
2
1
89
·
--
#dusk $DUSK @Dusk_Foundation Encontrei uma decisão de design no DUSK que inicialmente pareceu contraditória.
Se o DUSK tem seu próprio ambiente de execução, por que construir uma rota baseada em EVM de qualquer forma?
Pense em um aeroporto especializado.
Você pode construir uma aeronave totalmente nova do zero.
Mas se você quer que milhares de pilotos existentes usem seu aeroporto, dar a eles uma pista familiar torna a adoção muito mais fácil.
Foi isso que me deixou interessado no DuskEVM.
O DUSK já tem o DuskVM para contratos que precisam de acesso direto ao L1.
Mesmo assim, o DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum — Solidity, Vyper, ferramentas e carteiras EVM padrão — enquanto usa o DuskDS por baixo para liquidação e disponibilidade de dados.
Então percebi o Hedger.
É a evolução do Zedger, mas construído sobre o DuskEVM — essencialmente trazendo o foco do DUSK em ativos regulados para um ambiente em primeiro lugar no EVM.
Isso me diz algo sobre a estratégia do DUSK.
Não parece estar dizendo:
“Esqueça o Ethereum. Aprenda nossa stack.”
Está mais para:
“Permaneça com a porta familiar do desenvolvedor, mas conecte-a a uma infraestrutura projetada para finanças reguladas.”
E isso importa porque superioridade técnica significa pouco se os desenvolvedores precisarem abandonar as ferramentas que já conhecem antes de conseguir usá-la.
Então a pergunta interessante não é:
“O DUSK suporta EVM?
É:
“A infraestrutura financeira consegue continuar especializada sem forçar o ecossistema de desenvolvedores a começar do zero?”
É isso que vou observar com o Hedger.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Encontrei uma decisão de design no DUSK que inicialmente pareceu contraditória.
Se o DUSK tem seu próprio ambiente de execução, por que construir uma rota baseada em EVM de qualquer forma?
Pense em um aeroporto especializado.
Você pode construir uma aeronave totalmente nova do zero.
Mas se você quer que milhares de pilotos existentes usem seu aeroporto, dar a eles uma pista familiar torna a adoção muito mais fácil.
Foi isso que me deixou interessado no DuskEVM.
O DUSK já tem o DuskVM para contratos que precisam de acesso direto ao L1.
Mesmo assim, o DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum — Solidity, Vyper, ferramentas e carteiras EVM padrão — enquanto usa o DuskDS por baixo para liquidação e disponibilidade de dados.
Então percebi o Hedger.
É a evolução do Zedger, mas construído sobre o DuskEVM — essencialmente trazendo o foco do DUSK em ativos regulados para um ambiente em primeiro lugar no EVM.
Isso me diz algo sobre a estratégia do DUSK.
Não parece estar dizendo:
“Esqueça o Ethereum. Aprenda nossa stack.”
Está mais para:
“Permaneça com a porta familiar do desenvolvedor, mas conecte-a a uma infraestrutura projetada para finanças reguladas.”
E isso importa porque superioridade técnica significa pouco se os desenvolvedores precisarem abandonar as ferramentas que já conhecem antes de conseguir usá-la.
Então a pergunta interessante não é:
“O DUSK suporta EVM?
É:
“A infraestrutura financeira consegue continuar especializada sem forçar o ecossistema de desenvolvedores a começar do zero?”
É isso que vou observar com o Hedger.
#dusk $DUSK @Dusk
Se o DUSK tem seu próprio ambiente de execução, por que construir uma rota baseada em EVM de qualquer forma?
Pense em um aeroporto especializado.
Você pode construir uma aeronave totalmente nova do zero.
Mas se você quer que milhares de pilotos existentes usem seu aeroporto, dar a eles uma pista familiar torna a adoção muito mais fácil.
Foi isso que me deixou interessado no DuskEVM.
O DUSK já tem o DuskVM para contratos que precisam de acesso direto ao L1.
Mesmo assim, o DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum — Solidity, Vyper, ferramentas e carteiras EVM padrão — enquanto usa o DuskDS por baixo para liquidação e disponibilidade de dados.
Então percebi o Hedger.
É a evolução do Zedger, mas construído sobre o DuskEVM — essencialmente trazendo o foco do DUSK em ativos regulados para um ambiente em primeiro lugar no EVM.
Isso me diz algo sobre a estratégia do DUSK.
Não parece estar dizendo:
“Esqueça o Ethereum. Aprenda nossa stack.”
Está mais para:
“Permaneça com a porta familiar do desenvolvedor, mas conecte-a a uma infraestrutura projetada para finanças reguladas.”
E isso importa porque superioridade técnica significa pouco se os desenvolvedores precisarem abandonar as ferramentas que já conhecem antes de conseguir usá-la.
Então a pergunta interessante não é:
“O DUSK suporta EVM?
É:
“A infraestrutura financeira consegue continuar especializada sem forçar o ecossistema de desenvolvedores a começar do zero?”
É isso que vou observar com o Hedger.
#dusk $DUSK @Dusk
82
·
--
#dusk $DUSK @Dusk_Foundation Notei algo que inicialmente não fazia muito sentido.
Se a DUSK quer que os desenvolvedores construam aplicações financeiras, por que criar o seu próprio ambiente de execução quando o EVM já existe?
Imagine abrir uma oficina especializada ao lado de uma grande fábrica multiuso.
A fábrica consegue fabricar quase tudo.
Mas a sua oficina é projetada para um único tipo de trabalho.
Essa foi a diferença que encontrei entre DuskVM e DuskEVM.
DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum: Solidity, Vyper, as ferramentas padrão do EVM e carteiras.
Mas DuskVM segue outro caminho.
Ele executa diretamente contratos inteligentes Rust/WASM na Dusk L1, dando aos contratos acesso direto aos modelos nativos de transação da Dusk, ativos, privacidade e capacidades de zero-knowledge.
Isso fez a arquitetura “clicar” para mim.
A DUSK não está forçando que toda aplicação caia em um único modelo de execução.
Ela mantém o ambiente familiar para compatibilidade...
...enquanto preserva um ambiente nativo para aplicações que precisam de acesso mais profundo à L1.
E isso importa porque aplicações financeiras reguladas nem sempre são contratos DeFi comuns.
Algumas precisam das próprias primitivas subjacentes de liquidação e privacidade.
Então talvez a pergunta interessante não seja:
“Por que a DUSK tem duas VMs?”
É:
“O que acontece quando compatibilidade e especialização são tratadas como dois problemas de engenharia diferentes?”
Essa troca de compromissos me diz muito sobre o que a DUSK realmente está tentando construir.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Notei algo que inicialmente não fazia muito sentido.
Se a DUSK quer que os desenvolvedores construam aplicações financeiras, por que criar o seu próprio ambiente de execução quando o EVM já existe?
Imagine abrir uma oficina especializada ao lado de uma grande fábrica multiuso.
A fábrica consegue fabricar quase tudo.
Mas a sua oficina é projetada para um único tipo de trabalho.
Essa foi a diferença que encontrei entre DuskVM e DuskEVM.
DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum: Solidity, Vyper, as ferramentas padrão do EVM e carteiras.
Mas DuskVM segue outro caminho.
Ele executa diretamente contratos inteligentes Rust/WASM na Dusk L1, dando aos contratos acesso direto aos modelos nativos de transação da Dusk, ativos, privacidade e capacidades de zero-knowledge.
Isso fez a arquitetura “clicar” para mim.
A DUSK não está forçando que toda aplicação caia em um único modelo de execução.
Ela mantém o ambiente familiar para compatibilidade...
...enquanto preserva um ambiente nativo para aplicações que precisam de acesso mais profundo à L1.
E isso importa porque aplicações financeiras reguladas nem sempre são contratos DeFi comuns.
Algumas precisam das próprias primitivas subjacentes de liquidação e privacidade.
Então talvez a pergunta interessante não seja:
“Por que a DUSK tem duas VMs?”
É:
“O que acontece quando compatibilidade e especialização são tratadas como dois problemas de engenharia diferentes?”
Essa troca de compromissos me diz muito sobre o que a DUSK realmente está tentando construir.
#dusk $DUSK @Dusk
Se a DUSK quer que os desenvolvedores construam aplicações financeiras, por que criar o seu próprio ambiente de execução quando o EVM já existe?
Imagine abrir uma oficina especializada ao lado de uma grande fábrica multiuso.
A fábrica consegue fabricar quase tudo.
Mas a sua oficina é projetada para um único tipo de trabalho.
Essa foi a diferença que encontrei entre DuskVM e DuskEVM.
DuskEVM oferece aos desenvolvedores o ambiente familiar do Ethereum: Solidity, Vyper, as ferramentas padrão do EVM e carteiras.
Mas DuskVM segue outro caminho.
Ele executa diretamente contratos inteligentes Rust/WASM na Dusk L1, dando aos contratos acesso direto aos modelos nativos de transação da Dusk, ativos, privacidade e capacidades de zero-knowledge.
Isso fez a arquitetura “clicar” para mim.
A DUSK não está forçando que toda aplicação caia em um único modelo de execução.
Ela mantém o ambiente familiar para compatibilidade...
...enquanto preserva um ambiente nativo para aplicações que precisam de acesso mais profundo à L1.
E isso importa porque aplicações financeiras reguladas nem sempre são contratos DeFi comuns.
Algumas precisam das próprias primitivas subjacentes de liquidação e privacidade.
Então talvez a pergunta interessante não seja:
“Por que a DUSK tem duas VMs?”
É:
“O que acontece quando compatibilidade e especialização são tratadas como dois problemas de engenharia diferentes?”
Essa troca de compromissos me diz muito sobre o que a DUSK realmente está tentando construir.
#dusk $DUSK @Dusk
7
1
121
·
--
#dusk $DUSK @Dusk_Foundation Encontrei um detalhe no design de consenso da DUSK que me fez repensar o que “descentralizado” realmente significa.
Imagine um tribunal em que as mesmas 20 pessoas julgam cada caso.
Mesmo que elas sejam honestas, você provavelmente começaria a perguntar:
Por que eles?
Agora imagine que o júri seja escolhido aleatoriamente para cada caso.
Pessoas diferentes analisam as evidências, outro grupo confirma a decisão e, uma vez que o veredito seja ratificado, o caso é encerrado.
Esse foi o modelo mental que me ajudou a entender a Attestation Succinct (SA) da DUSK.
Em vez de haver um grupo fixo responsável por cada bloco, a DUSK usa provisioners selecionados aleatoriamente em comitês.
Um comitê pode propor e outro pode validar e ratificar o resultado.
A parte interessante é o que acontece depois da ratificação:
o bloco atinge a finalidade determinística.
Então comecei a olhar para isso menos como “mais um design de Proof-of-Stake” e mais como um problema de coordenação.
Se os mesmos validadores controlassem permanentemente toda decisão, a descentralização poderia, aos poucos, virar uma questão de quem ocupa a cadeira.
A seleção aleatória de comitês muda essa dinâmica.
E eu acho que existe um motivo pelo qual a DUSK se importa com essa arquitetura.
Infraestrutura financeira não precisa apenas de blocos para serem produzidos.
Ela precisa de um processo em que os participantes do mercado consigam saber quando uma decisão realmente é final.
É essa a parte que eu acho interessante na SA:
A DUSK não perguntou apenas quem deveria validar o próximo bloco. Ela projetou um processo para decidir quem tem o direito de julgá-lo — e quando esse julgamento se torna final.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Encontrei um detalhe no design de consenso da DUSK que me fez repensar o que “descentralizado” realmente significa.
Imagine um tribunal em que as mesmas 20 pessoas julgam cada caso.
Mesmo que elas sejam honestas, você provavelmente começaria a perguntar:
Por que eles?
Agora imagine que o júri seja escolhido aleatoriamente para cada caso.
Pessoas diferentes analisam as evidências, outro grupo confirma a decisão e, uma vez que o veredito seja ratificado, o caso é encerrado.
Esse foi o modelo mental que me ajudou a entender a Attestation Succinct (SA) da DUSK.
Em vez de haver um grupo fixo responsável por cada bloco, a DUSK usa provisioners selecionados aleatoriamente em comitês.
Um comitê pode propor e outro pode validar e ratificar o resultado.
A parte interessante é o que acontece depois da ratificação:
o bloco atinge a finalidade determinística.
Então comecei a olhar para isso menos como “mais um design de Proof-of-Stake” e mais como um problema de coordenação.
Se os mesmos validadores controlassem permanentemente toda decisão, a descentralização poderia, aos poucos, virar uma questão de quem ocupa a cadeira.
A seleção aleatória de comitês muda essa dinâmica.
E eu acho que existe um motivo pelo qual a DUSK se importa com essa arquitetura.
Infraestrutura financeira não precisa apenas de blocos para serem produzidos.
Ela precisa de um processo em que os participantes do mercado consigam saber quando uma decisão realmente é final.
É essa a parte que eu acho interessante na SA:
A DUSK não perguntou apenas quem deveria validar o próximo bloco. Ela projetou um processo para decidir quem tem o direito de julgá-lo — e quando esse julgamento se torna final.
#dusk $DUSK @Dusk
Imagine um tribunal em que as mesmas 20 pessoas julgam cada caso.
Mesmo que elas sejam honestas, você provavelmente começaria a perguntar:
Por que eles?
Agora imagine que o júri seja escolhido aleatoriamente para cada caso.
Pessoas diferentes analisam as evidências, outro grupo confirma a decisão e, uma vez que o veredito seja ratificado, o caso é encerrado.
Esse foi o modelo mental que me ajudou a entender a Attestation Succinct (SA) da DUSK.
Em vez de haver um grupo fixo responsável por cada bloco, a DUSK usa provisioners selecionados aleatoriamente em comitês.
Um comitê pode propor e outro pode validar e ratificar o resultado.
A parte interessante é o que acontece depois da ratificação:
o bloco atinge a finalidade determinística.
Então comecei a olhar para isso menos como “mais um design de Proof-of-Stake” e mais como um problema de coordenação.
Se os mesmos validadores controlassem permanentemente toda decisão, a descentralização poderia, aos poucos, virar uma questão de quem ocupa a cadeira.
A seleção aleatória de comitês muda essa dinâmica.
E eu acho que existe um motivo pelo qual a DUSK se importa com essa arquitetura.
Infraestrutura financeira não precisa apenas de blocos para serem produzidos.
Ela precisa de um processo em que os participantes do mercado consigam saber quando uma decisão realmente é final.
É essa a parte que eu acho interessante na SA:
A DUSK não perguntou apenas quem deveria validar o próximo bloco. Ela projetou um processo para decidir quem tem o direito de julgá-lo — e quando esse julgamento se torna final.
#dusk $DUSK @Dusk
1
102
·
--
#dusk $DUSK @Dusk_Foundation Encontrei um problema com “liquidação instantânea” que eu não tinha pensado realmente.
E se o ativo chegar antes do dinheiro?
Imagine comprar uma casa.
O vendedor te entrega as chaves primeiro.
Você promete pagar amanhã.
Tecnicamente, a transferência de propriedade aconteceu rapidamente.
Mas a transação ainda está exposta a um problema muito antigo:
Uma das partes já entregou. A outra não.
A mesma lacuna existe nos mercados financeiros quando a perna do ativo e a perna do pagamento são tratadas separadamente.
Então eu analisei o que a DUSK está construindo em torno disso.
Sua infraestrutura de mercado foi projetada para coordenar a perna do ativo e a perna do pagamento, com liquidação determinística por baixo. A Dusk Trade descreve isso como coordenar os dois lados de uma negociação regulada, em vez de tratar a transferência de ativo como um evento isolado.
Isso parece uma pequena decisão arquitetural.
Mas eu não acho que seja.
Porque o problema real da liquidação não é simplesmente:
“Quão rápido o token pode se mover?”
É:
“Como os dois lados da transação sabem que o acordo realmente foi concluído?”
A resposta da DUSK é trazer as duas pernas para o mesmo fluxo de liquidação.
Essa é uma ideia muito diferente de apenas colocar valores mobiliários na cadeia.
Você não está apenas digitalizando o ativo.
Você está tentando coordenar a própria troca.
E isso me deixou com uma pergunta:
Se o ativo e o pagamento ainda são liquidados de forma independente, podemos realmente chamar isso de liquidação atômica?
@Dusk_Foundation $DUSK #Dusk.
#dusk $DUSK @Dusk Encontrei um problema com “liquidação instantânea” que eu não tinha pensado realmente.
E se o ativo chegar antes do dinheiro?
Imagine comprar uma casa.
O vendedor te entrega as chaves primeiro.
Você promete pagar amanhã.
Tecnicamente, a transferência de propriedade aconteceu rapidamente.
Mas a transação ainda está exposta a um problema muito antigo:
Uma das partes já entregou. A outra não.
A mesma lacuna existe nos mercados financeiros quando a perna do ativo e a perna do pagamento são tratadas separadamente.
Então eu analisei o que a DUSK está construindo em torno disso.
Sua infraestrutura de mercado foi projetada para coordenar a perna do ativo e a perna do pagamento, com liquidação determinística por baixo. A Dusk Trade descreve isso como coordenar os dois lados de uma negociação regulada, em vez de tratar a transferência de ativo como um evento isolado.
Isso parece uma pequena decisão arquitetural.
Mas eu não acho que seja.
Porque o problema real da liquidação não é simplesmente:
“Quão rápido o token pode se mover?”
É:
“Como os dois lados da transação sabem que o acordo realmente foi concluído?”
A resposta da DUSK é trazer as duas pernas para o mesmo fluxo de liquidação.
Essa é uma ideia muito diferente de apenas colocar valores mobiliários na cadeia.
Você não está apenas digitalizando o ativo.
Você está tentando coordenar a própria troca.
E isso me deixou com uma pergunta:
Se o ativo e o pagamento ainda são liquidados de forma independente, podemos realmente chamar isso de liquidação atômica?
@Dusk $DUSK #Dusk.
E se o ativo chegar antes do dinheiro?
Imagine comprar uma casa.
O vendedor te entrega as chaves primeiro.
Você promete pagar amanhã.
Tecnicamente, a transferência de propriedade aconteceu rapidamente.
Mas a transação ainda está exposta a um problema muito antigo:
Uma das partes já entregou. A outra não.
A mesma lacuna existe nos mercados financeiros quando a perna do ativo e a perna do pagamento são tratadas separadamente.
Então eu analisei o que a DUSK está construindo em torno disso.
Sua infraestrutura de mercado foi projetada para coordenar a perna do ativo e a perna do pagamento, com liquidação determinística por baixo. A Dusk Trade descreve isso como coordenar os dois lados de uma negociação regulada, em vez de tratar a transferência de ativo como um evento isolado.
Isso parece uma pequena decisão arquitetural.
Mas eu não acho que seja.
Porque o problema real da liquidação não é simplesmente:
“Quão rápido o token pode se mover?”
É:
“Como os dois lados da transação sabem que o acordo realmente foi concluído?”
A resposta da DUSK é trazer as duas pernas para o mesmo fluxo de liquidação.
Essa é uma ideia muito diferente de apenas colocar valores mobiliários na cadeia.
Você não está apenas digitalizando o ativo.
Você está tentando coordenar a própria troca.
E isso me deixou com uma pergunta:
Se o ativo e o pagamento ainda são liquidados de forma independente, podemos realmente chamar isso de liquidação atômica?
@Dusk $DUSK #Dusk.
94
·
--
#dusk $DUSK @Dusk_Foundation Eu continuei vendo “ativos tokenizados” descritos como se a parte difícil terminasse quando o token muda de mãos.
Isso me fez parar.
Imagine comprar as ações de uma empresa.
A compra está concluída.
Mas o que acontece quando a empresa declara um dividendo?
Convoca uma votação de acionistas?
Muda os termos do título?
Envia uma atualização aos investidores?
O registro de propriedade ainda precisa fazer algo.
É aí que encontrei outra parte interessante da arquitetura da DUSK: o asset servicing (serviço de ativos).
O design da infraestrutura de mercado da DUSK trata ativos regulados como mais do que tokens transferíveis.
O fluxo de trabalho também precisa lidar com coisas como corporate actions (eventos corporativos), atualizações para investidores, relatórios e trilhas de auditoria, além de emissão, transferências e liquidação.
Isso muda a forma como eu vejo tokenização.
Um token que consegue se mover da Wallet A para a Wallet B é apenas um momento na vida de um ativo.
A pergunta mais difícil é:
O que acontece com o ativo depois da negociação?
Se dividendos, votações, mudanças de propriedade e relatórios ainda dependem de sistemas desconectados, então o blockchain pode ter digitalizado a transferência sem realmente digitalizar o ciclo de vida do ativo.
É por isso que a abordagem da DUSK chamou minha atenção.
Ela não está apenas perguntando:
“Podemos colocar títulos na cadeia?”
Parece estar perguntando:
“O ativo consegue continuar funcionando na cadeia depois que chega lá?”
E, sinceramente, eu acho que esse é o problema mais difícil.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Eu continuei vendo “ativos tokenizados” descritos como se a parte difícil terminasse quando o token muda de mãos.
Isso me fez parar.
Imagine comprar as ações de uma empresa.
A compra está concluída.
Mas o que acontece quando a empresa declara um dividendo?
Convoca uma votação de acionistas?
Muda os termos do título?
Envia uma atualização aos investidores?
O registro de propriedade ainda precisa fazer algo.
É aí que encontrei outra parte interessante da arquitetura da DUSK: o asset servicing (serviço de ativos).
O design da infraestrutura de mercado da DUSK trata ativos regulados como mais do que tokens transferíveis.
O fluxo de trabalho também precisa lidar com coisas como corporate actions (eventos corporativos), atualizações para investidores, relatórios e trilhas de auditoria, além de emissão, transferências e liquidação.
Isso muda a forma como eu vejo tokenização.
Um token que consegue se mover da Wallet A para a Wallet B é apenas um momento na vida de um ativo.
A pergunta mais difícil é:
O que acontece com o ativo depois da negociação?
Se dividendos, votações, mudanças de propriedade e relatórios ainda dependem de sistemas desconectados, então o blockchain pode ter digitalizado a transferência sem realmente digitalizar o ciclo de vida do ativo.
É por isso que a abordagem da DUSK chamou minha atenção.
Ela não está apenas perguntando:
“Podemos colocar títulos na cadeia?”
Parece estar perguntando:
“O ativo consegue continuar funcionando na cadeia depois que chega lá?”
E, sinceramente, eu acho que esse é o problema mais difícil.
#dusk $DUSK @Dusk
Isso me fez parar.
Imagine comprar as ações de uma empresa.
A compra está concluída.
Mas o que acontece quando a empresa declara um dividendo?
Convoca uma votação de acionistas?
Muda os termos do título?
Envia uma atualização aos investidores?
O registro de propriedade ainda precisa fazer algo.
É aí que encontrei outra parte interessante da arquitetura da DUSK: o asset servicing (serviço de ativos).
O design da infraestrutura de mercado da DUSK trata ativos regulados como mais do que tokens transferíveis.
O fluxo de trabalho também precisa lidar com coisas como corporate actions (eventos corporativos), atualizações para investidores, relatórios e trilhas de auditoria, além de emissão, transferências e liquidação.
Isso muda a forma como eu vejo tokenização.
Um token que consegue se mover da Wallet A para a Wallet B é apenas um momento na vida de um ativo.
A pergunta mais difícil é:
O que acontece com o ativo depois da negociação?
Se dividendos, votações, mudanças de propriedade e relatórios ainda dependem de sistemas desconectados, então o blockchain pode ter digitalizado a transferência sem realmente digitalizar o ciclo de vida do ativo.
É por isso que a abordagem da DUSK chamou minha atenção.
Ela não está apenas perguntando:
“Podemos colocar títulos na cadeia?”
Parece estar perguntando:
“O ativo consegue continuar funcionando na cadeia depois que chega lá?”
E, sinceramente, eu acho que esse é o problema mais difícil.
#dusk $DUSK @Dusk
3
2
102
·
--
#dusk $DUSK @Dusk_Foundation A tokenização deveria tornar os mercados financeiros mais fáceis de acessar.
Mas isso me fez pensar:
O que acontece quando o ativo fica mais fácil de acessar do que as regras sobre quem pode possuí-lo?
Imagine um leilão privado.
O leilão é totalmente digital.
Os lances são instantâneos.
Mas ainda assim há uma lista de convidados.
Poder ver o leilão não significa que você está autorizado a comprar o que está sendo vendido.
Essa distinção se torna importante com ativos regulados.
Eu analisei como a DUSK lida com isso e encontrei controles de acesso + vinculação da carteira dentro do design da infraestrutura de mercado.
A ideia é simples:
Primeiro, estabelecer que um participante é elegível.
Depois, vincular esse participante verificado à carteira que interage com o ativo.
Então, as transferências podem ser verificadas de acordo com as regras.
Assim, a blockchain não fica apenas registrando:
“Carteira A enviou um ativo para a Carteira B.”
A pergunta mais interessante passa a ser:
“A Carteira B realmente estava autorizada a recebê-lo?”
Isso muda o que “compliance onchain” significa para mim.
Não é apenas armazenar um resultado de KYC em algum lugar.
É conectar identidade → elegibilidade → carteira → transferência dentro do mesmo fluxo de trabalho do ativo.
E isso fica ainda mais interessante à medida que a tokenização tenta abrir mercados tradicionalmente privados para mais investidores.
Porque tornar um ativo mais fácil de acessar só é útil se a infraestrutura ainda conseguir responder:
Quem é autorizado a passar pela porta? #dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk A tokenização deveria tornar os mercados financeiros mais fáceis de acessar.
Mas isso me fez pensar:
O que acontece quando o ativo fica mais fácil de acessar do que as regras sobre quem pode possuí-lo?
Imagine um leilão privado.
O leilão é totalmente digital.
Os lances são instantâneos.
Mas ainda assim há uma lista de convidados.
Poder ver o leilão não significa que você está autorizado a comprar o que está sendo vendido.
Essa distinção se torna importante com ativos regulados.
Eu analisei como a DUSK lida com isso e encontrei controles de acesso + vinculação da carteira dentro do design da infraestrutura de mercado.
A ideia é simples:
Primeiro, estabelecer que um participante é elegível.
Depois, vincular esse participante verificado à carteira que interage com o ativo.
Então, as transferências podem ser verificadas de acordo com as regras.
Assim, a blockchain não fica apenas registrando:
“Carteira A enviou um ativo para a Carteira B.”
A pergunta mais interessante passa a ser:
“A Carteira B realmente estava autorizada a recebê-lo?”
Isso muda o que “compliance onchain” significa para mim.
Não é apenas armazenar um resultado de KYC em algum lugar.
É conectar identidade → elegibilidade → carteira → transferência dentro do mesmo fluxo de trabalho do ativo.
E isso fica ainda mais interessante à medida que a tokenização tenta abrir mercados tradicionalmente privados para mais investidores.
Porque tornar um ativo mais fácil de acessar só é útil se a infraestrutura ainda conseguir responder:
Quem é autorizado a passar pela porta? #dusk $DUSK @Dusk
Mas isso me fez pensar:
O que acontece quando o ativo fica mais fácil de acessar do que as regras sobre quem pode possuí-lo?
Imagine um leilão privado.
O leilão é totalmente digital.
Os lances são instantâneos.
Mas ainda assim há uma lista de convidados.
Poder ver o leilão não significa que você está autorizado a comprar o que está sendo vendido.
Essa distinção se torna importante com ativos regulados.
Eu analisei como a DUSK lida com isso e encontrei controles de acesso + vinculação da carteira dentro do design da infraestrutura de mercado.
A ideia é simples:
Primeiro, estabelecer que um participante é elegível.
Depois, vincular esse participante verificado à carteira que interage com o ativo.
Então, as transferências podem ser verificadas de acordo com as regras.
Assim, a blockchain não fica apenas registrando:
“Carteira A enviou um ativo para a Carteira B.”
A pergunta mais interessante passa a ser:
“A Carteira B realmente estava autorizada a recebê-lo?”
Isso muda o que “compliance onchain” significa para mim.
Não é apenas armazenar um resultado de KYC em algum lugar.
É conectar identidade → elegibilidade → carteira → transferência dentro do mesmo fluxo de trabalho do ativo.
E isso fica ainda mais interessante à medida que a tokenização tenta abrir mercados tradicionalmente privados para mais investidores.
Porque tornar um ativo mais fácil de acessar só é útil se a infraestrutura ainda conseguir responder:
Quem é autorizado a passar pela porta? #dusk $DUSK @Dusk
3
3
96
·
--
#dusk $DUSK @Dusk_Foundation Comecei a me perguntar por que provar que sou elegível para algo geralmente significa entregar toda a minha identidade.
Imagine um clube noturno verificando se você tem mais de 18 anos.
Faria sentido o segurança tirar uma cópia do seu passaporte inteiro só para verificar um fato.
Basicamente, esse foi o problema que encontrei ao investigar mais a fundo o KYC digital.
A instituição precisa saber.
“Essa pessoa atende ao requisito?
Mas a verificação tradicional muitas vezes entrega muito mais.
nome, endereço, data de nascimento, detalhes do documento.
Então eu analisei como a DUSK lida com isso junto com a Citadel.
A Citadel usa provas de conhecimento zero para que o usuário possa provar que possui uma credencial válida sem expor as informações subjacentes em si. O protocolo dela pode emitir uma licença na blockchain e, então, permitir que o usuário prove a posse de uma licença válida ao solicitar um serviço.
Isso muda a relação entre KYC e privacidade.
Em vez de.
“Aqui está minha identidade. Verifique tudo.
Passa a ser.
“Aqui está uma prova criptográfica de que eu atendo ao requisito.
E acho que isso explica por que a DUSK precisava da Citadel.
Se o objetivo é levar as finanças reguladas para a blockchain, a conformidade não pode simplesmente desaparecer.
Mas também não deveria ser necessário que toda interação financeira exija outra cópia dos dados pessoais de alguém.
A pergunta interessante não é se o KYC deve existir.
É.
Quanta informação provar elegibilidade realmente deve exigir que você revele?
@Dusk_Foundation $DUSK
#dusk
#dusk $DUSK @Dusk Comecei a me perguntar por que provar que sou elegível para algo geralmente significa entregar toda a minha identidade.
Imagine um clube noturno verificando se você tem mais de 18 anos.
Faria sentido o segurança tirar uma cópia do seu passaporte inteiro só para verificar um fato.
Basicamente, esse foi o problema que encontrei ao investigar mais a fundo o KYC digital.
A instituição precisa saber.
“Essa pessoa atende ao requisito?
Mas a verificação tradicional muitas vezes entrega muito mais.
nome, endereço, data de nascimento, detalhes do documento.
Então eu analisei como a DUSK lida com isso junto com a Citadel.
A Citadel usa provas de conhecimento zero para que o usuário possa provar que possui uma credencial válida sem expor as informações subjacentes em si. O protocolo dela pode emitir uma licença na blockchain e, então, permitir que o usuário prove a posse de uma licença válida ao solicitar um serviço.
Isso muda a relação entre KYC e privacidade.
Em vez de.
“Aqui está minha identidade. Verifique tudo.
Passa a ser.
“Aqui está uma prova criptográfica de que eu atendo ao requisito.
E acho que isso explica por que a DUSK precisava da Citadel.
Se o objetivo é levar as finanças reguladas para a blockchain, a conformidade não pode simplesmente desaparecer.
Mas também não deveria ser necessário que toda interação financeira exija outra cópia dos dados pessoais de alguém.
A pergunta interessante não é se o KYC deve existir.
É.
Quanta informação provar elegibilidade realmente deve exigir que você revele?
@Dusk $DUSK
#dusk
Imagine um clube noturno verificando se você tem mais de 18 anos.
Faria sentido o segurança tirar uma cópia do seu passaporte inteiro só para verificar um fato.
Basicamente, esse foi o problema que encontrei ao investigar mais a fundo o KYC digital.
A instituição precisa saber.
“Essa pessoa atende ao requisito?
Mas a verificação tradicional muitas vezes entrega muito mais.
nome, endereço, data de nascimento, detalhes do documento.
Então eu analisei como a DUSK lida com isso junto com a Citadel.
A Citadel usa provas de conhecimento zero para que o usuário possa provar que possui uma credencial válida sem expor as informações subjacentes em si. O protocolo dela pode emitir uma licença na blockchain e, então, permitir que o usuário prove a posse de uma licença válida ao solicitar um serviço.
Isso muda a relação entre KYC e privacidade.
Em vez de.
“Aqui está minha identidade. Verifique tudo.
Passa a ser.
“Aqui está uma prova criptográfica de que eu atendo ao requisito.
E acho que isso explica por que a DUSK precisava da Citadel.
Se o objetivo é levar as finanças reguladas para a blockchain, a conformidade não pode simplesmente desaparecer.
Mas também não deveria ser necessário que toda interação financeira exija outra cópia dos dados pessoais de alguém.
A pergunta interessante não é se o KYC deve existir.
É.
Quanta informação provar elegibilidade realmente deve exigir que você revele?
@Dusk $DUSK
#dusk
14
4
89
·
--
#dusk $DUSK @Dusk_Foundation Eu estava olhando para como uma segurança normal é transferida, e uma coisa me incomodou.
O ativo pode se mover.
Mas quem verifica se foi realmente permitido que ele se movesse?
Pense em um clube privado.
Ter um cartão de associação não significa automaticamente que você pode entregá-lo a qualquer pessoa. Existem regras sobre quem pode entrar, quem pode recebê-lo e quando uma transferência é permitida.
Isso me fez olhar mais a fundo para o Zedger da DUSK.
O Zedger não é apenas sobre criar um ativo digital.
Ele foi projetado para a emissão e a gestão privadas e em conformidade de ativos regulados, em que coisas como elegibilidade, restrições de transferência e privacidade podem se tornar parte do fluxo de trabalho.
Isso importa porque valores mobiliários regulados não são tokens comuns.
Uma obrigação, por exemplo, pode ter regras sobre quem pode mantê-la, como ela pode se mover e quais informações diferentes participantes têm permissão para ver.
A DUSK parece estar fazendo uma pergunta mais interessante:
E se o livro de regras do ativo não ficasse em uma planilha ou banco de dados separado, mas passasse a fazer parte da infraestrutura que gerencia o próprio ativo?
Por isso o Zedger chamou minha atenção.
A parte interessante não é colocar uma segurança on-chain.
É tornar as regras sobre aquela segurança executáveis junto com ela.
@Dusk_Foundation $DUSK #dusk
#dusk $DUSK @Dusk Eu estava olhando para como uma segurança normal é transferida, e uma coisa me incomodou.
O ativo pode se mover.
Mas quem verifica se foi realmente permitido que ele se movesse?
Pense em um clube privado.
Ter um cartão de associação não significa automaticamente que você pode entregá-lo a qualquer pessoa. Existem regras sobre quem pode entrar, quem pode recebê-lo e quando uma transferência é permitida.
Isso me fez olhar mais a fundo para o Zedger da DUSK.
O Zedger não é apenas sobre criar um ativo digital.
Ele foi projetado para a emissão e a gestão privadas e em conformidade de ativos regulados, em que coisas como elegibilidade, restrições de transferência e privacidade podem se tornar parte do fluxo de trabalho.
Isso importa porque valores mobiliários regulados não são tokens comuns.
Uma obrigação, por exemplo, pode ter regras sobre quem pode mantê-la, como ela pode se mover e quais informações diferentes participantes têm permissão para ver.
A DUSK parece estar fazendo uma pergunta mais interessante:
E se o livro de regras do ativo não ficasse em uma planilha ou banco de dados separado, mas passasse a fazer parte da infraestrutura que gerencia o próprio ativo?
Por isso o Zedger chamou minha atenção.
A parte interessante não é colocar uma segurança on-chain.
É tornar as regras sobre aquela segurança executáveis junto com ela.
@Dusk $DUSK #dusk
O ativo pode se mover.
Mas quem verifica se foi realmente permitido que ele se movesse?
Pense em um clube privado.
Ter um cartão de associação não significa automaticamente que você pode entregá-lo a qualquer pessoa. Existem regras sobre quem pode entrar, quem pode recebê-lo e quando uma transferência é permitida.
Isso me fez olhar mais a fundo para o Zedger da DUSK.
O Zedger não é apenas sobre criar um ativo digital.
Ele foi projetado para a emissão e a gestão privadas e em conformidade de ativos regulados, em que coisas como elegibilidade, restrições de transferência e privacidade podem se tornar parte do fluxo de trabalho.
Isso importa porque valores mobiliários regulados não são tokens comuns.
Uma obrigação, por exemplo, pode ter regras sobre quem pode mantê-la, como ela pode se mover e quais informações diferentes participantes têm permissão para ver.
A DUSK parece estar fazendo uma pergunta mais interessante:
E se o livro de regras do ativo não ficasse em uma planilha ou banco de dados separado, mas passasse a fazer parte da infraestrutura que gerencia o próprio ativo?
Por isso o Zedger chamou minha atenção.
A parte interessante não é colocar uma segurança on-chain.
É tornar as regras sobre aquela segurança executáveis junto com ela.
@Dusk $DUSK #dusk
3
2
83
·
--
#dusk $DUSK Comecei a pensar sobre alguma coisa enquanto investigava o DUSK.
Quando alguém diz “este título está on-chain”, o que exatamente está on-chain?
Imagine colocar a foto de um carro em um banco de dados digital.
A foto é digital.
Mas os registros reais de propriedade, seguro, manutenção e registro ainda estão em escritórios diferentes.
Esse é, em linhas gerais, o problema que encontrei com a simples tokenização.
Um token pode representar um ativo financeiro, enquanto o ciclo de vida real do ativo ainda depende de sistemas separados.
O DUSK segue um caminho diferente com a emissão nativa.
Em vez de tratar o token da blockchain apenas como um invólucro, o ativo pode ser criado e gerenciado em torno do próprio livro-razão — com emissão, propriedade, transferências, manutenção e liquidação projetadas como parte do mesmo fluxo de trabalho.
Essa diferença parece pequena.
Mas muda a pergunta de:
“Podemos colocar um ativo financeiro on-chain?”
para:
“O ativo consegue realmente viver o ciclo de vida dele on-chain?”
Acho que é por isso que o DUSK adotou a emissão nativa.
O objetivo não é outro token.
É reduzir o número de registros e encaminhamentos separados dos quais um ativo regulamentado depende.
E isso me faz pensar:
Se o fluxo de trabalho financeiro subjacente ainda vive off-chain, quanto desse ativo, de fato, colocamos on-chain?
@Dusk_Foundation $DUSK #duks
#dusk $DUSK Comecei a pensar sobre alguma coisa enquanto investigava o DUSK.
Quando alguém diz “este título está on-chain”, o que exatamente está on-chain?
Imagine colocar a foto de um carro em um banco de dados digital.
A foto é digital.
Mas os registros reais de propriedade, seguro, manutenção e registro ainda estão em escritórios diferentes.
Esse é, em linhas gerais, o problema que encontrei com a simples tokenização.
Um token pode representar um ativo financeiro, enquanto o ciclo de vida real do ativo ainda depende de sistemas separados.
O DUSK segue um caminho diferente com a emissão nativa.
Em vez de tratar o token da blockchain apenas como um invólucro, o ativo pode ser criado e gerenciado em torno do próprio livro-razão — com emissão, propriedade, transferências, manutenção e liquidação projetadas como parte do mesmo fluxo de trabalho.
Essa diferença parece pequena.
Mas muda a pergunta de:
“Podemos colocar um ativo financeiro on-chain?”
para:
“O ativo consegue realmente viver o ciclo de vida dele on-chain?”
Acho que é por isso que o DUSK adotou a emissão nativa.
O objetivo não é outro token.
É reduzir o número de registros e encaminhamentos separados dos quais um ativo regulamentado depende.
E isso me faz pensar:
Se o fluxo de trabalho financeiro subjacente ainda vive off-chain, quanto desse ativo, de fato, colocamos on-chain?
@Dusk $DUSK #duks
Quando alguém diz “este título está on-chain”, o que exatamente está on-chain?
Imagine colocar a foto de um carro em um banco de dados digital.
A foto é digital.
Mas os registros reais de propriedade, seguro, manutenção e registro ainda estão em escritórios diferentes.
Esse é, em linhas gerais, o problema que encontrei com a simples tokenização.
Um token pode representar um ativo financeiro, enquanto o ciclo de vida real do ativo ainda depende de sistemas separados.
O DUSK segue um caminho diferente com a emissão nativa.
Em vez de tratar o token da blockchain apenas como um invólucro, o ativo pode ser criado e gerenciado em torno do próprio livro-razão — com emissão, propriedade, transferências, manutenção e liquidação projetadas como parte do mesmo fluxo de trabalho.
Essa diferença parece pequena.
Mas muda a pergunta de:
“Podemos colocar um ativo financeiro on-chain?”
para:
“O ativo consegue realmente viver o ciclo de vida dele on-chain?”
Acho que é por isso que o DUSK adotou a emissão nativa.
O objetivo não é outro token.
É reduzir o número de registros e encaminhamentos separados dos quais um ativo regulamentado depende.
E isso me faz pensar:
Se o fluxo de trabalho financeiro subjacente ainda vive off-chain, quanto desse ativo, de fato, colocamos on-chain?
@Dusk $DUSK #duks
9
3
130
·
--
#dusk $DUSK Notei algo estranho ao analisar a atividade da DUSK.
Por que uma cadeia focada em privacidade manteria deliberadamente um sistema público de transações?
Pense em um banco com duas portas.
Uma porta dá para um saguão público.
Todos podem ver quem entrou e o que aconteceu.
A outra leva a uma sala privada.
Apenas as pessoas envolvidas conhecem os detalhes.
Isso é surpreendentemente parecido com como a DUSK funciona.
A luz do luar é a porta pública: contas, saldos, remetente, destinatário e valores podem ficar visíveis.
A Fênix é a porta privada: os fundos se movem como notas protegidas (shielded), com provas de conhecimento zero ocultando detalhes sensíveis das transações.
E isto não é apenas teórico.
Ao observar a atividade on-chain da DUSK, ambos os modelos de transação estão realmente sendo usados — transações públicas do Moonlight junto com atividades protegidas da Phoenix.
Então por que construir os dois?
Porque a infraestrutura financeira não precisa de “tudo privado”.
Alguns fluxos exigem transparência.
Outros precisam de confidencialidade.
A aposta interessante da DUSK é que a privacidade deve ser uma ferramenta que você pode usar, e não uma regra imposta a cada transação.
Isso parece muito mais próximo de como os mercados financeiros reais funcionam.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK Notei algo estranho ao analisar a atividade da DUSK.
Por que uma cadeia focada em privacidade manteria deliberadamente um sistema público de transações?
Pense em um banco com duas portas.
Uma porta dá para um saguão público.
Todos podem ver quem entrou e o que aconteceu.
A outra leva a uma sala privada.
Apenas as pessoas envolvidas conhecem os detalhes.
Isso é surpreendentemente parecido com como a DUSK funciona.
A luz do luar é a porta pública: contas, saldos, remetente, destinatário e valores podem ficar visíveis.
A Fênix é a porta privada: os fundos se movem como notas protegidas (shielded), com provas de conhecimento zero ocultando detalhes sensíveis das transações.
E isto não é apenas teórico.
Ao observar a atividade on-chain da DUSK, ambos os modelos de transação estão realmente sendo usados — transações públicas do Moonlight junto com atividades protegidas da Phoenix.
Então por que construir os dois?
Porque a infraestrutura financeira não precisa de “tudo privado”.
Alguns fluxos exigem transparência.
Outros precisam de confidencialidade.
A aposta interessante da DUSK é que a privacidade deve ser uma ferramenta que você pode usar, e não uma regra imposta a cada transação.
Isso parece muito mais próximo de como os mercados financeiros reais funcionam.
#dusk $DUSK @Dusk
Por que uma cadeia focada em privacidade manteria deliberadamente um sistema público de transações?
Pense em um banco com duas portas.
Uma porta dá para um saguão público.
Todos podem ver quem entrou e o que aconteceu.
A outra leva a uma sala privada.
Apenas as pessoas envolvidas conhecem os detalhes.
Isso é surpreendentemente parecido com como a DUSK funciona.
A luz do luar é a porta pública: contas, saldos, remetente, destinatário e valores podem ficar visíveis.
A Fênix é a porta privada: os fundos se movem como notas protegidas (shielded), com provas de conhecimento zero ocultando detalhes sensíveis das transações.
E isto não é apenas teórico.
Ao observar a atividade on-chain da DUSK, ambos os modelos de transação estão realmente sendo usados — transações públicas do Moonlight junto com atividades protegidas da Phoenix.
Então por que construir os dois?
Porque a infraestrutura financeira não precisa de “tudo privado”.
Alguns fluxos exigem transparência.
Outros precisam de confidencialidade.
A aposta interessante da DUSK é que a privacidade deve ser uma ferramenta que você pode usar, e não uma regra imposta a cada transação.
Isso parece muito mais próximo de como os mercados financeiros reais funcionam.
#dusk $DUSK @Dusk
7
4
93
·
--
#dusk $DUSK Por que construir um cofre particular… e depois dar uma chave a alguém?
Imagine manter seus documentos financeiros dentro de uma sala trancada.
Você não quer que todo visitante os leia.
Mas quando um auditor chega, você ainda precisa de uma forma de provar o que está lá dentro.
Foi aí que as chaves de visualização Phoenix da DUSK chamaram minha atenção.
A Phoenix mantém os detalhes das transações protegidos, mas as chaves de visualização permitem que os usuários revelem informações de forma seletiva para partes autorizadas.
Então privacidade não significa:
“Esconder tudo para sempre.”
Significa:
“Decidir quem pode ver o quê.”
Isso importa para os mercados financeiros porque um investidor talvez não queira que suas transações sejam expostas a todos na cadeia, enquanto um auditor ou parte autorizada ainda pode precisar de evidências específicas.
A DUSK adotou essa abordagem porque o setor financeiro regulado precisa de privacidade e responsabilização ao mesmo tempo.
Essa é uma definição de privacidade muito mais prática.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk_Foundation
#dusk $DUSK Por que construir um cofre particular… e depois dar uma chave a alguém?
Imagine manter seus documentos financeiros dentro de uma sala trancada.
Você não quer que todo visitante os leia.
Mas quando um auditor chega, você ainda precisa de uma forma de provar o que está lá dentro.
Foi aí que as chaves de visualização Phoenix da DUSK chamaram minha atenção.
A Phoenix mantém os detalhes das transações protegidos, mas as chaves de visualização permitem que os usuários revelem informações de forma seletiva para partes autorizadas.
Então privacidade não significa:
“Esconder tudo para sempre.”
Significa:
“Decidir quem pode ver o quê.”
Isso importa para os mercados financeiros porque um investidor talvez não queira que suas transações sejam expostas a todos na cadeia, enquanto um auditor ou parte autorizada ainda pode precisar de evidências específicas.
A DUSK adotou essa abordagem porque o setor financeiro regulado precisa de privacidade e responsabilização ao mesmo tempo.
Essa é uma definição de privacidade muito mais prática.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk
Imagine manter seus documentos financeiros dentro de uma sala trancada.
Você não quer que todo visitante os leia.
Mas quando um auditor chega, você ainda precisa de uma forma de provar o que está lá dentro.
Foi aí que as chaves de visualização Phoenix da DUSK chamaram minha atenção.
A Phoenix mantém os detalhes das transações protegidos, mas as chaves de visualização permitem que os usuários revelem informações de forma seletiva para partes autorizadas.
Então privacidade não significa:
“Esconder tudo para sempre.”
Significa:
“Decidir quem pode ver o quê.”
Isso importa para os mercados financeiros porque um investidor talvez não queira que suas transações sejam expostas a todos na cadeia, enquanto um auditor ou parte autorizada ainda pode precisar de evidências específicas.
A DUSK adotou essa abordagem porque o setor financeiro regulado precisa de privacidade e responsabilização ao mesmo tempo.
Essa é uma definição de privacidade muito mais prática.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk
12
5
315
·
--
Em Alta
#baby $BABY Você já reparou que a maioria dos argumentos não é sobre o que aconteceu, e sim sobre quando aconteceu?
Percebi isso enquanto ouvia dois amigos contarem a mesma história de uma viagem que fizemos juntos.
Nenhum deles estava inventando. Eles apenas lembraram a ordem dos acontecimentos de formas diferentes e, de algum jeito, isso mudou toda a história.
Isso me fez pensar em blockchains.
À medida que mais redes começam a interagir, elas também precisam de um jeito compartilhado de concordar sobre o histórico. Caso contrário, cada uma pode acabar acreditando na sua própria versão do que aconteceu primeiro.
Uma das coisas que achei interessante na Babylon é exatamente essa.
Em vez de pedir que cada cadeia confie no cronograma de outra cadeia, a Babylon permite que elas fixem checkpoints importantes no Bitcoin. Isso oferece a redes independentes um ponto de referência comum quando a finalização realmente importa.
No começo, eu me perguntei por que a Babylon escolheu essa abordagem em vez de simplesmente tornar tudo mais rápido.
Aí entendi: quando você está protegendo valor, a certeza costuma ser mais importante do que a velocidade.
Claro que existe um trade-off. Esperar pela finalização respaldada pelo Bitcoin pode levar mais tempo do que depender apenas da confirmação local. Mas se o objetivo é impedir histórias conflitantes, esse tempo extra começa a parecer menos um atraso e mais uma salvaguarda.
Talvez o futuro do Bitcoin não seja apenas ser o lugar mais confiável para armazenar valor.
Talvez seja o lugar para onde outras redes olham quando precisam de certeza.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Você já reparou que a maioria dos argumentos não é sobre o que aconteceu, e sim sobre quando aconteceu?
Percebi isso enquanto ouvia dois amigos contarem a mesma história de uma viagem que fizemos juntos.
Nenhum deles estava inventando. Eles apenas lembraram a ordem dos acontecimentos de formas diferentes e, de algum jeito, isso mudou toda a história.
Isso me fez pensar em blockchains.
À medida que mais redes começam a interagir, elas também precisam de um jeito compartilhado de concordar sobre o histórico. Caso contrário, cada uma pode acabar acreditando na sua própria versão do que aconteceu primeiro.
Uma das coisas que achei interessante na Babylon é exatamente essa.
Em vez de pedir que cada cadeia confie no cronograma de outra cadeia, a Babylon permite que elas fixem checkpoints importantes no Bitcoin. Isso oferece a redes independentes um ponto de referência comum quando a finalização realmente importa.
No começo, eu me perguntei por que a Babylon escolheu essa abordagem em vez de simplesmente tornar tudo mais rápido.
Aí entendi: quando você está protegendo valor, a certeza costuma ser mais importante do que a velocidade.
Claro que existe um trade-off. Esperar pela finalização respaldada pelo Bitcoin pode levar mais tempo do que depender apenas da confirmação local. Mas se o objetivo é impedir histórias conflitantes, esse tempo extra começa a parecer menos um atraso e mais uma salvaguarda.
Talvez o futuro do Bitcoin não seja apenas ser o lugar mais confiável para armazenar valor.
Talvez seja o lugar para onde outras redes olham quando precisam de certeza.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Percebi isso enquanto ouvia dois amigos contarem a mesma história de uma viagem que fizemos juntos.
Nenhum deles estava inventando. Eles apenas lembraram a ordem dos acontecimentos de formas diferentes e, de algum jeito, isso mudou toda a história.
Isso me fez pensar em blockchains.
À medida que mais redes começam a interagir, elas também precisam de um jeito compartilhado de concordar sobre o histórico. Caso contrário, cada uma pode acabar acreditando na sua própria versão do que aconteceu primeiro.
Uma das coisas que achei interessante na Babylon é exatamente essa.
Em vez de pedir que cada cadeia confie no cronograma de outra cadeia, a Babylon permite que elas fixem checkpoints importantes no Bitcoin. Isso oferece a redes independentes um ponto de referência comum quando a finalização realmente importa.
No começo, eu me perguntei por que a Babylon escolheu essa abordagem em vez de simplesmente tornar tudo mais rápido.
Aí entendi: quando você está protegendo valor, a certeza costuma ser mais importante do que a velocidade.
Claro que existe um trade-off. Esperar pela finalização respaldada pelo Bitcoin pode levar mais tempo do que depender apenas da confirmação local. Mas se o objetivo é impedir histórias conflitantes, esse tempo extra começa a parecer menos um atraso e mais uma salvaguarda.
Talvez o futuro do Bitcoin não seja apenas ser o lugar mais confiável para armazenar valor.
Talvez seja o lugar para onde outras redes olham quando precisam de certeza.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
6
2
150
·
--
#baby $BABY Você já reparou que as equipes mais fortes não esperam que todo mundo faça tudo?
Percebi isso enquanto assistia a uma partida de críquete local.
O capitão não era o arremessador mais rápido. O defensor (wicketkeeper) não estava abrindo a sequência de arremessos. Todo mundo tinha um papel diferente, e de algum jeito isso deixou o time mais forte.
Essa ideia voltou quando eu estava lendo sobre Babylon.
Uma coisa que achei interessante é que quem tem Bitcoin não precisa fazer todo o trabalho técnico sozinho. Babylon introduz os Provedores de Finalidade (Finality Providers), cuja função é ajudar a finalizar blocos e proteger a rede, enquanto os detentores de BTC podem contribuir com segurança por meio de staking.
No começo, eu me perguntei por que o Babylon não simplesmente fez com que cada participante (staker) cuidasse de tudo.
Aí fez sentido. A maioria dos detentores de Bitcoin apenas quer apoiar a rede sem executar uma infraestrutura complexa. Ao separar essas responsabilidades, Babylon torna a participação mais prática, mantendo tarefas críticas nas mãos de operadores dedicados.
Claro, há um custo. Esses operadores assumem mais responsabilidades, e por isso o protocolo precisa de incentivos fortes e responsabilização para manter o sistema seguro.
Quanto mais eu penso nisso, mais eu valorizo projetos que não exigem que todo mundo faça o mesmo trabalho. Às vezes, uma rede mais forte nasce de dar a cada participante um papel que ele realmente consegue desempenhar bem.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Você já reparou que as equipes mais fortes não esperam que todo mundo faça tudo?
Percebi isso enquanto assistia a uma partida de críquete local.
O capitão não era o arremessador mais rápido. O defensor (wicketkeeper) não estava abrindo a sequência de arremessos. Todo mundo tinha um papel diferente, e de algum jeito isso deixou o time mais forte.
Essa ideia voltou quando eu estava lendo sobre Babylon.
Uma coisa que achei interessante é que quem tem Bitcoin não precisa fazer todo o trabalho técnico sozinho. Babylon introduz os Provedores de Finalidade (Finality Providers), cuja função é ajudar a finalizar blocos e proteger a rede, enquanto os detentores de BTC podem contribuir com segurança por meio de staking.
No começo, eu me perguntei por que o Babylon não simplesmente fez com que cada participante (staker) cuidasse de tudo.
Aí fez sentido. A maioria dos detentores de Bitcoin apenas quer apoiar a rede sem executar uma infraestrutura complexa. Ao separar essas responsabilidades, Babylon torna a participação mais prática, mantendo tarefas críticas nas mãos de operadores dedicados.
Claro, há um custo. Esses operadores assumem mais responsabilidades, e por isso o protocolo precisa de incentivos fortes e responsabilização para manter o sistema seguro.
Quanto mais eu penso nisso, mais eu valorizo projetos que não exigem que todo mundo faça o mesmo trabalho. Às vezes, uma rede mais forte nasce de dar a cada participante um papel que ele realmente consegue desempenhar bem.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Percebi isso enquanto assistia a uma partida de críquete local.
O capitão não era o arremessador mais rápido. O defensor (wicketkeeper) não estava abrindo a sequência de arremessos. Todo mundo tinha um papel diferente, e de algum jeito isso deixou o time mais forte.
Essa ideia voltou quando eu estava lendo sobre Babylon.
Uma coisa que achei interessante é que quem tem Bitcoin não precisa fazer todo o trabalho técnico sozinho. Babylon introduz os Provedores de Finalidade (Finality Providers), cuja função é ajudar a finalizar blocos e proteger a rede, enquanto os detentores de BTC podem contribuir com segurança por meio de staking.
No começo, eu me perguntei por que o Babylon não simplesmente fez com que cada participante (staker) cuidasse de tudo.
Aí fez sentido. A maioria dos detentores de Bitcoin apenas quer apoiar a rede sem executar uma infraestrutura complexa. Ao separar essas responsabilidades, Babylon torna a participação mais prática, mantendo tarefas críticas nas mãos de operadores dedicados.
Claro, há um custo. Esses operadores assumem mais responsabilidades, e por isso o protocolo precisa de incentivos fortes e responsabilização para manter o sistema seguro.
Quanto mais eu penso nisso, mais eu valorizo projetos que não exigem que todo mundo faça o mesmo trabalho. Às vezes, uma rede mais forte nasce de dar a cada participante um papel que ele realmente consegue desempenhar bem.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
10
4
144
·
--
#baby $BABY E se a coisa mais valiosa que o Bitcoin pode oferecer não fosse dinheiro... mas tempo?
Essa pergunta me pegou de surpresa enquanto eu lia sobre a Babylon.
Sempre pensei no Bitcoin como o lugar onde o valor é armazenado. Eu nunca imaginei que algo tão simples quanto um carimbo de data e hora pudesse ser uma de suas maiores forças.
Pense assim. Se alguém registra um evento em um caderno hoje, qualquer pessoa poderia depois argumentar sobre quando ele realmente foi escrito. Mas se o mesmo evento for registrado permanentemente no Bitcoin, alterar sua história se torna incrivelmente difícil.
Foi isso que achei interessante no mecanismo de timestamping da Babylon. Em vez de pedir que outras redes confiem cegamente umas nas outras, ele permite que elas fixem pontos de verificação importantes na linha do tempo do Bitcoin. Assim, todo mundo consegue verificar quando algo aconteceu, sem depender de uma única parte.
Quanto mais eu aprendi sobre isso, mais percebi que o futuro do Bitcoin talvez não seja apenas sobre proteger riqueza. Ele também pode se tornar o relógio que ajuda outras redes de blockchain a permanecerem honestas.
Esse era um papel que eu nunca esperava que o Bitcoin desempenhasse.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY E se a coisa mais valiosa que o Bitcoin pode oferecer não fosse dinheiro... mas tempo?
Essa pergunta me pegou de surpresa enquanto eu lia sobre a Babylon.
Sempre pensei no Bitcoin como o lugar onde o valor é armazenado. Eu nunca imaginei que algo tão simples quanto um carimbo de data e hora pudesse ser uma de suas maiores forças.
Pense assim. Se alguém registra um evento em um caderno hoje, qualquer pessoa poderia depois argumentar sobre quando ele realmente foi escrito. Mas se o mesmo evento for registrado permanentemente no Bitcoin, alterar sua história se torna incrivelmente difícil.
Foi isso que achei interessante no mecanismo de timestamping da Babylon. Em vez de pedir que outras redes confiem cegamente umas nas outras, ele permite que elas fixem pontos de verificação importantes na linha do tempo do Bitcoin. Assim, todo mundo consegue verificar quando algo aconteceu, sem depender de uma única parte.
Quanto mais eu aprendi sobre isso, mais percebi que o futuro do Bitcoin talvez não seja apenas sobre proteger riqueza. Ele também pode se tornar o relógio que ajuda outras redes de blockchain a permanecerem honestas.
Esse era um papel que eu nunca esperava que o Bitcoin desempenhasse.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Essa pergunta me pegou de surpresa enquanto eu lia sobre a Babylon.
Sempre pensei no Bitcoin como o lugar onde o valor é armazenado. Eu nunca imaginei que algo tão simples quanto um carimbo de data e hora pudesse ser uma de suas maiores forças.
Pense assim. Se alguém registra um evento em um caderno hoje, qualquer pessoa poderia depois argumentar sobre quando ele realmente foi escrito. Mas se o mesmo evento for registrado permanentemente no Bitcoin, alterar sua história se torna incrivelmente difícil.
Foi isso que achei interessante no mecanismo de timestamping da Babylon. Em vez de pedir que outras redes confiem cegamente umas nas outras, ele permite que elas fixem pontos de verificação importantes na linha do tempo do Bitcoin. Assim, todo mundo consegue verificar quando algo aconteceu, sem depender de uma única parte.
Quanto mais eu aprendi sobre isso, mais percebi que o futuro do Bitcoin talvez não seja apenas sobre proteger riqueza. Ele também pode se tornar o relógio que ajuda outras redes de blockchain a permanecerem honestas.
Esse era um papel que eu nunca esperava que o Bitcoin desempenhasse.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
21
4
131
·
--
#baby $BABY Eu sempre achei que a parte mais difícil de construir uma blockchain era a tecnologia. Agora não tenho tanta certeza.
Uma conversa com um amigo mudou a forma como eu vejo isso. Estávamos discutindo novos projetos, e ele fez uma pergunta simples: "Quem de fato tem uma chance justa de fazer parte?"
Eu não tinha uma resposta na hora.
Quanto mais eu pensava, mais percebia que distribuição não é apenas sobre entregar tokens. Ela determina quem entra no começo, quem ajuda a garantir a rede e quem cresce com o ecossistema ao longo do tempo.
É por isso que Babylon chamou minha atenção. Se o mecanismo de distribuição foi criado para tornar a participação mais acessível, em vez de recompensar apenas um pequeno grupo, então ele está fazendo mais do que lançar um token. Ele está definindo o tom para o tipo de comunidade que quer construir.
No fim das contas, a grande tecnologia importa. Mas às vezes, a forma como as pessoas são convidadas importa tanto quanto.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Eu sempre achei que a parte mais difícil de construir uma blockchain era a tecnologia. Agora não tenho tanta certeza.
Uma conversa com um amigo mudou a forma como eu vejo isso. Estávamos discutindo novos projetos, e ele fez uma pergunta simples: "Quem de fato tem uma chance justa de fazer parte?"
Eu não tinha uma resposta na hora.
Quanto mais eu pensava, mais percebia que distribuição não é apenas sobre entregar tokens. Ela determina quem entra no começo, quem ajuda a garantir a rede e quem cresce com o ecossistema ao longo do tempo.
É por isso que Babylon chamou minha atenção. Se o mecanismo de distribuição foi criado para tornar a participação mais acessível, em vez de recompensar apenas um pequeno grupo, então ele está fazendo mais do que lançar um token. Ele está definindo o tom para o tipo de comunidade que quer construir.
No fim das contas, a grande tecnologia importa. Mas às vezes, a forma como as pessoas são convidadas importa tanto quanto.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Uma conversa com um amigo mudou a forma como eu vejo isso. Estávamos discutindo novos projetos, e ele fez uma pergunta simples: "Quem de fato tem uma chance justa de fazer parte?"
Eu não tinha uma resposta na hora.
Quanto mais eu pensava, mais percebia que distribuição não é apenas sobre entregar tokens. Ela determina quem entra no começo, quem ajuda a garantir a rede e quem cresce com o ecossistema ao longo do tempo.
É por isso que Babylon chamou minha atenção. Se o mecanismo de distribuição foi criado para tornar a participação mais acessível, em vez de recompensar apenas um pequeno grupo, então ele está fazendo mais do que lançar um token. Ele está definindo o tom para o tipo de comunidade que quer construir.
No fim das contas, a grande tecnologia importa. Mas às vezes, a forma como as pessoas são convidadas importa tanto quanto.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
8
2
83
·
--
#baby $BABY Aqui vai uma versão mais humana e reflexiva, que parece a análise de uma pessoa de verdade, em vez de um conteúdo promocional:
E se o Bitcoin nunca tivesse que escolher entre segurança e utilidade?
Essa ideia me atingiu enquanto colocava a conversa em dia com um velho amigo. Ele tem BTC há anos, mas toda vez que o assunto virava DeFi, ele dava a mesma resposta: "Eu não quero mover meu Bitcoin só para ganhar um pouco mais." Eu não podia culpá-lo. A maioria das opções parecia trocar certeza por oportunidade.
Quanto mais eu olhava para o Babylon, mais eu percebia que a conversa talvez estivesse mudando. Em vez de tirar o BTC nativo do Bitcoin, a ideia é fazer com que ele se torne um colateral rápido para o DeFi, permanecendo nativo. Isso parece uma direção bem diferente.
Se essa abordagem se provar ao longo do tempo, ela pode remover uma das maiores barreiras psicológicas para quem mantém Bitcoin a longo prazo. Talvez o futuro do BTCFi não seja convencer as pessoas a confiar em algo novo—talvez seja dar a elas uma forma de usar aquilo em que elas já confiam.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Aqui vai uma versão mais humana e reflexiva, que parece a análise de uma pessoa de verdade, em vez de um conteúdo promocional:
E se o Bitcoin nunca tivesse que escolher entre segurança e utilidade?
Essa ideia me atingiu enquanto colocava a conversa em dia com um velho amigo. Ele tem BTC há anos, mas toda vez que o assunto virava DeFi, ele dava a mesma resposta: "Eu não quero mover meu Bitcoin só para ganhar um pouco mais." Eu não podia culpá-lo. A maioria das opções parecia trocar certeza por oportunidade.
Quanto mais eu olhava para o Babylon, mais eu percebia que a conversa talvez estivesse mudando. Em vez de tirar o BTC nativo do Bitcoin, a ideia é fazer com que ele se torne um colateral rápido para o DeFi, permanecendo nativo. Isso parece uma direção bem diferente.
Se essa abordagem se provar ao longo do tempo, ela pode remover uma das maiores barreiras psicológicas para quem mantém Bitcoin a longo prazo. Talvez o futuro do BTCFi não seja convencer as pessoas a confiar em algo novo—talvez seja dar a elas uma forma de usar aquilo em que elas já confiam.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
E se o Bitcoin nunca tivesse que escolher entre segurança e utilidade?
Essa ideia me atingiu enquanto colocava a conversa em dia com um velho amigo. Ele tem BTC há anos, mas toda vez que o assunto virava DeFi, ele dava a mesma resposta: "Eu não quero mover meu Bitcoin só para ganhar um pouco mais." Eu não podia culpá-lo. A maioria das opções parecia trocar certeza por oportunidade.
Quanto mais eu olhava para o Babylon, mais eu percebia que a conversa talvez estivesse mudando. Em vez de tirar o BTC nativo do Bitcoin, a ideia é fazer com que ele se torne um colateral rápido para o DeFi, permanecendo nativo. Isso parece uma direção bem diferente.
Se essa abordagem se provar ao longo do tempo, ela pode remover uma das maiores barreiras psicológicas para quem mantém Bitcoin a longo prazo. Talvez o futuro do BTCFi não seja convencer as pessoas a confiar em algo novo—talvez seja dar a elas uma forma de usar aquilo em que elas já confiam.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
11
5
167
·
--
#baby $BABY Eu conheço bem essa sensação horrível de afundar.
Ver os fundos sumirem porque uma ponte em que você confiava de repente caiu é brutal.
Sem aviso. Só um saldo zero encarando você.
Isso faz você perceber o quão arriscado é depender de pontes duvidosas ou de comitês centralizados de multi-assinatura.
Essa mesma frustração é o motivo pelo qual os detentores que apoiam o $baby já estão fartos de promessas vazias e querem uma segurança inabalável.
É aqui que o EOTS muda tudo.
Em vez de você cruzar os dedos esperando que um comitê realmente puna os maus atores, o protocolo resolve isso com matemática pura.
Se um validador tentar fazer dupla assinatura e trapacear a rede, sua chave privada é vazada diretamente na cadeia como punição instantânea.
A descentralização de verdade não é sobre confiar que as pessoas farão a coisa certa.
É sobre construir um sistema em que a trapaça é matematicamente impossível.
A matemática sempre vence.
Para ser sincero, faz você se perguntar—se a segurança se torna totalmente autoexecutável, quanto tempo até as pontes tradicionais virarem coisa do passado?$BABY #baby @babylonlabs_io
#baby $BABY Eu conheço bem essa sensação horrível de afundar.
Ver os fundos sumirem porque uma ponte em que você confiava de repente caiu é brutal.
Sem aviso. Só um saldo zero encarando você.
Isso faz você perceber o quão arriscado é depender de pontes duvidosas ou de comitês centralizados de multi-assinatura.
Essa mesma frustração é o motivo pelo qual os detentores que apoiam o $baby já estão fartos de promessas vazias e querem uma segurança inabalável.
É aqui que o EOTS muda tudo.
Em vez de você cruzar os dedos esperando que um comitê realmente puna os maus atores, o protocolo resolve isso com matemática pura.
Se um validador tentar fazer dupla assinatura e trapacear a rede, sua chave privada é vazada diretamente na cadeia como punição instantânea.
A descentralização de verdade não é sobre confiar que as pessoas farão a coisa certa.
É sobre construir um sistema em que a trapaça é matematicamente impossível.
A matemática sempre vence.
Para ser sincero, faz você se perguntar—se a segurança se torna totalmente autoexecutável, quanto tempo até as pontes tradicionais virarem coisa do passado?$BABY #baby @BabylonLabs_io
Ver os fundos sumirem porque uma ponte em que você confiava de repente caiu é brutal.
Sem aviso. Só um saldo zero encarando você.
Isso faz você perceber o quão arriscado é depender de pontes duvidosas ou de comitês centralizados de multi-assinatura.
Essa mesma frustração é o motivo pelo qual os detentores que apoiam o $baby já estão fartos de promessas vazias e querem uma segurança inabalável.
É aqui que o EOTS muda tudo.
Em vez de você cruzar os dedos esperando que um comitê realmente puna os maus atores, o protocolo resolve isso com matemática pura.
Se um validador tentar fazer dupla assinatura e trapacear a rede, sua chave privada é vazada diretamente na cadeia como punição instantânea.
A descentralização de verdade não é sobre confiar que as pessoas farão a coisa certa.
É sobre construir um sistema em que a trapaça é matematicamente impossível.
A matemática sempre vence.
Para ser sincero, faz você se perguntar—se a segurança se torna totalmente autoexecutável, quanto tempo até as pontes tradicionais virarem coisa do passado?$BABY #baby @BabylonLabs_io
2
2
130
·
--
#newt $NEWT Algo clicou para mim hoje.
Sempre que há um hack ou uma negociação ruim, todo mundo começa a falar sobre segurança. Mas, até lá, a transação já aconteceu.
Isso me fez pensar por que aceitamos isso como algo normal.
Talvez a melhoria maior não seja reagir mais rápido. Talvez seja impedir transações arriscadas antes que elas sequer sejam executadas.
Uma das razões pelas quais tenho acompanhado @NewtonProtocol com mais atenção. O Newton Protocol está construindo uma rede de infraestrutura descentralizada para hospedar, executar e verificar modelos de IA. O que acho interessante é que ele está se movendo em direção à avaliação de risco antes da execução, enquanto separa a inferência da verificação para que a IA responda rapidamente e as provas possam ser confirmadas depois.
Se essa ideia funcionar na prática, ela pode mudar a forma como as finanças on-chain lidam com a confiança. A oportunidade é enorme. Ao mesmo tempo, uma boa infraestrutura ainda precisa de adoção real, e isso nunca é garantido.
Por isso, vejo isso como algo que vale a pena observar — não porque eu espere resultados instantâneos, mas porque a própria direção parece diferente.
Se a IA vai tomar mais decisões on-chain, a prioridade deve ser corrigir erros depois ou impedir que eles aconteçam antes? $NEWT #Newt @NewtonProtocol
#newt $NEWT Algo clicou para mim hoje.
Sempre que há um hack ou uma negociação ruim, todo mundo começa a falar sobre segurança. Mas, até lá, a transação já aconteceu.
Isso me fez pensar por que aceitamos isso como algo normal.
Talvez a melhoria maior não seja reagir mais rápido. Talvez seja impedir transações arriscadas antes que elas sequer sejam executadas.
Uma das razões pelas quais tenho acompanhado @NewtonProtocol com mais atenção. O Newton Protocol está construindo uma rede de infraestrutura descentralizada para hospedar, executar e verificar modelos de IA. O que acho interessante é que ele está se movendo em direção à avaliação de risco antes da execução, enquanto separa a inferência da verificação para que a IA responda rapidamente e as provas possam ser confirmadas depois.
Se essa ideia funcionar na prática, ela pode mudar a forma como as finanças on-chain lidam com a confiança. A oportunidade é enorme. Ao mesmo tempo, uma boa infraestrutura ainda precisa de adoção real, e isso nunca é garantido.
Por isso, vejo isso como algo que vale a pena observar — não porque eu espere resultados instantâneos, mas porque a própria direção parece diferente.
Se a IA vai tomar mais decisões on-chain, a prioridade deve ser corrigir erros depois ou impedir que eles aconteçam antes? $NEWT #Newt @NewtonProtocol
Sempre que há um hack ou uma negociação ruim, todo mundo começa a falar sobre segurança. Mas, até lá, a transação já aconteceu.
Isso me fez pensar por que aceitamos isso como algo normal.
Talvez a melhoria maior não seja reagir mais rápido. Talvez seja impedir transações arriscadas antes que elas sequer sejam executadas.
Uma das razões pelas quais tenho acompanhado @NewtonProtocol com mais atenção. O Newton Protocol está construindo uma rede de infraestrutura descentralizada para hospedar, executar e verificar modelos de IA. O que acho interessante é que ele está se movendo em direção à avaliação de risco antes da execução, enquanto separa a inferência da verificação para que a IA responda rapidamente e as provas possam ser confirmadas depois.
Se essa ideia funcionar na prática, ela pode mudar a forma como as finanças on-chain lidam com a confiança. A oportunidade é enorme. Ao mesmo tempo, uma boa infraestrutura ainda precisa de adoção real, e isso nunca é garantido.
Por isso, vejo isso como algo que vale a pena observar — não porque eu espere resultados instantâneos, mas porque a própria direção parece diferente.
Se a IA vai tomar mais decisões on-chain, a prioridade deve ser corrigir erros depois ou impedir que eles aconteçam antes? $NEWT #Newt @NewtonProtocol
2
2
91
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
Tópicos em Tendência
RevolutConfirmsFakeGovEmailDataBreach
83 visualizações
31 a discutir
#RevolutConfirmsFakeGovEmailDataBreach Ataque à Revolut.
A Revolut recebeu um pedido de informações que parecia ter origem em uma agência governamental legítima. O pedido partiu de uma conta de e-mail não autorizada, mas criada diretamente na infraestrutura do domínio oficial. Como a mensagem trazia credenciais válidas de autenticação de domínio, a Revolut a atendeu "com a crença razoável" de que se tratava de uma solicitação autêntica.
Dados potencialmente comunicados:
• Identidade: nome completo, data de nascimento, profissão.
• Contato: endereço postal, e-mail, telefone.
• Documentos de KYC: cópia do documento de identificação (passaporte e/ou carteira de motorista) + selfie de verificação fornecida no momento de abertura da conta. A Revolut especifica que nenhum dado biométrico facial derivado (telemetria) foi transmitido — apenas a imagem do selfie.
• Dados financeiros: extratos de conta (IBAN, status, data de abertura, número de referência da carteira), histórico de saques, histórico completo de transações, incluindo Bitcoin.
Isso não foi uma violação dos servidores da Revolut, não houve senhas roubadas, nem valores foram movimentados. Foi engenharia social por meio do canal de solicitação legal.
Ironia muito comentada: a Revolut impõe um KYC pesado "para segurança e o combate ao crime", e então entrega tudo isso mediante uma intimação falsa.$ON $LAB $LSK
Isabella-I
·0 gostos
·110 visualizações
CanadaOSFISaysTokenizedDepositsEqualTraditionalDeposits
202 visualizações
20 a discutir
USBankCompletesCrossBorderPaymentPilotOnStellar
12,400 visualizações
380 a discutir