Recentemente entrei em contato com o sistema de provas de conhecimento zero Dusk da Rushel, que a equipa oficial está sempre a enfatizar como "alavancagem dinâmica" e "otimização de liquidez". Essas expressões parecem bastante abstratas, por isso consultei a documentação técnica e analisei com atenção.
Resumindo, a questão central na verdade aponta para o velho e conhecido sistema de provas ZK — demasiado rígido. O processo tradicional de geração de provas de conhecimento zero exige uma estrutura de circuito muito rigorosa; uma vez que a lógica de negócio é ajustada, toda a estrutura de prova pode precisar ser refeita do zero. Isto é um pesadelo para aplicações financeiras, pois a velocidade de mudança dos produtos financeiros é muito maior do que se imagina.
A "dinamicidade" que Rushel afirma na verdade pretende tornar o sistema de provas mais flexível e com maior capacidade de composição. Imagine um cenário de negociações a nível institucional — é necessário empacotar empréstimos, garantias e liquidações de derivativos numa única transação privada, cuja lógica também precisa de se ajustar dinamicamente consoante as condições de mercado. Rushel, através de provas recursivas e de um design de estado atualizável, aumenta significativamente a eficiência na geração de provas para negócios complexos. O mais importante é que não é preciso desenvolver uma nova estrutura de circuito para cada nova combinação de negócio.
Por que isso ajuda na liquidez? Porque liquidez não é apenas uma questão de volume de fundos. A verdadeira liquidez é a rapidez e o custo com que os fundos podem ser transferidos entre estratégias diferentes. Se o custo de proteção de privacidade tornar as transações rígidas e lentas, os fundos institucionais simplesmente não vão usar. O que Rushel quer fazer, na essência, é reduzir o "imposto do custo de privacidade".
Dito isto, todas essas vantagens ainda estão na fase teórica. O desempenho real só será conhecido quando for implementado na cadeia. Eu mesmo testei alguns dados na rede de testes e percebi que há uma grande diferença entre a "eficiência teórica" no campo ZK e a "experiência real". Espero que eles consigam realmente transformar esse sistema de alavancagem dinâmica em um produto — se não for possível, os usuários institucionais não vão se interessar pela história técnica, e tudo isso continuará sendo apenas teoria.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
7 gostos
Recompensa
7
5
Republicar
Partilhar
Comentar
0/400
ThreeHornBlasts
· 6h atrás
Embora a tese seja bem elaborada, só na cadeia de blocos é que se revela a verdadeira essência do regulamento, agora dizer qualquer coisa é em vão.
Depois de testar a rede de testes, a diferença parece bastante grande, teoria e prática são coisas completamente diferentes.
O conjunto ZK realmente enfrenta obstáculos, só resta esperar que Rushel consiga realmente quebrar o impasse.
Reduzir apenas o custo de privacidade por meio de impostos não é suficiente, é preciso que as instituições realmente utilizem para que seja uma vitória.
Provas recursivas parecem uma boa ideia, mas e os dados de desempenho? Mostrem-nos.
Para ser honesto, já vi muitos projetos desse tipo, no final todos fracassam na palavra "implementação".
A imaginação é bonita, a realidade é dura, vamos esperar eles lançarem o produto para conversar novamente.
Ver originalResponder0
CryptoMotivator
· 6h atrás
A teoria é muito bonita, mas ainda há poucos exemplos de falhas ao colocar na cadeia, desta vez será diferente? Tudo depende dos dados reais
Espera aí, eles realmente resolveram o problema da reconstrução de circuitos? Se for verdade, isso é realmente impressionante
Mais um projeto ZK que promete muito, falando de forma empolgante, primeiro quero ver o desempenho na testnet
O conceito de imposto de custo de privacidade é genial, vai direto ao ponto e toca na dor
Mas as instituições financeiras realmente arriscariam por essa melhoria de desempenho? Como é que garantem o risco?
Parece que a Rushel quer avançar na rota de provas recursivas, a ideia é boa, o difícil é a implementação prática
Resumindo, eles querem criar um middleware de liquidez ZK, uma ambição grande
Ver originalResponder0
MEVHunterZhang
· 6h atrás
A teoria é muito atraente, mas é na cadeia que a coisa fica séria. A prova recursiva do Rushel parece realmente interessante, só tenho medo de ser mais um projeto de PPT.
Parece estar abordando o verdadeiro ponto de dor financeiro, ajustando-se dinamicamente sem precisar reescrever o circuito toda vez, o que realmente economiza trabalho. Mas minha maior preocupação ainda é com o custo real de gas e a latência; os dados da testnet muitas vezes enganam.
A ideia de reduzir o custo de privacidade com provas de conhecimento zero é boa, só tenho medo de que no final ainda não consiga competir com a velocidade das soluções centralizadas. Vamos esperar por aplicações de nível institucional para ver, senão é tudo conversa fiada.
Se esse sistema realmente puder fazer com que transações privadas deixem de ser lentas, o Dusk realmente encontrou algo. Mas ainda é cedo para falar em "otimização de liquidez", afinal, no campo de ZK nunca faltaram projetos com teorias surpreendentes.
Tenho a impressão de que a abordagem do Rushel está certa, mas a dificuldade de execução pode ser maior do que o que está escrito na documentação. Os fundos institucionais não vão abrir mão de eficiência por privacidade, esse equilíbrio precisa ser bem ajustado.
Ver originalResponder0
BrokenRugs
· 7h atrás
Pode parecer abstrato, mas a questão central continua sendo a velha questão — teoria é bonita, só na cadeia se vê a verdade
Falar de teoria no papel é o mais irritante, vamos esperar para ver se Rushel consegue realmente implementar
As instituições não querem histórias, querem coisas que possam usar de fato
Esse abismo é um pouco grande, a teoria ZK e a realidade sempre estão um pouco distantes
Reduzir o custo de privacidade com impostos soa bem, mas onde estão os dados de desempenho?
Recentemente entrei em contato com o sistema de provas de conhecimento zero Dusk da Rushel, que a equipa oficial está sempre a enfatizar como "alavancagem dinâmica" e "otimização de liquidez". Essas expressões parecem bastante abstratas, por isso consultei a documentação técnica e analisei com atenção.
Resumindo, a questão central na verdade aponta para o velho e conhecido sistema de provas ZK — demasiado rígido. O processo tradicional de geração de provas de conhecimento zero exige uma estrutura de circuito muito rigorosa; uma vez que a lógica de negócio é ajustada, toda a estrutura de prova pode precisar ser refeita do zero. Isto é um pesadelo para aplicações financeiras, pois a velocidade de mudança dos produtos financeiros é muito maior do que se imagina.
A "dinamicidade" que Rushel afirma na verdade pretende tornar o sistema de provas mais flexível e com maior capacidade de composição. Imagine um cenário de negociações a nível institucional — é necessário empacotar empréstimos, garantias e liquidações de derivativos numa única transação privada, cuja lógica também precisa de se ajustar dinamicamente consoante as condições de mercado. Rushel, através de provas recursivas e de um design de estado atualizável, aumenta significativamente a eficiência na geração de provas para negócios complexos. O mais importante é que não é preciso desenvolver uma nova estrutura de circuito para cada nova combinação de negócio.
Por que isso ajuda na liquidez? Porque liquidez não é apenas uma questão de volume de fundos. A verdadeira liquidez é a rapidez e o custo com que os fundos podem ser transferidos entre estratégias diferentes. Se o custo de proteção de privacidade tornar as transações rígidas e lentas, os fundos institucionais simplesmente não vão usar. O que Rushel quer fazer, na essência, é reduzir o "imposto do custo de privacidade".
Dito isto, todas essas vantagens ainda estão na fase teórica. O desempenho real só será conhecido quando for implementado na cadeia. Eu mesmo testei alguns dados na rede de testes e percebi que há uma grande diferença entre a "eficiência teórica" no campo ZK e a "experiência real". Espero que eles consigam realmente transformar esse sistema de alavancagem dinâmica em um produto — se não for possível, os usuários institucionais não vão se interessar pela história técnica, e tudo isso continuará sendo apenas teoria.