Acho que o design de crosschain é mal interpretado porque as pessoas costumam focar em velocidade e taxas, enquanto ignoram onde o risco realmente mora.
A maioria das pontes depende de liquidez que fica em algum lugar, esperando para facilitar as transferências. Isso funciona até que a liquidez se torne escassa, fragmentada ou dependa de um pequeno conjunto de atores se comportando como esperado.
O modelo CCT da Dusk segue um caminho diferente. Em vez de passar por um pool, o ativo é removido de circulação em uma cadeia e recriado em outra por meio de um processo de queima e cunhagem.
O tradeoff é interessante.
Você não depende de liquidez disponível nem precisa se preocupar com slippage. Mas isso não torna o sistema isento de riscos. A hipótese crítica muda para saber se o evento de queima é verificado corretamente e se o processo de cunhagem é executado conforme o pretendido entre as cadeias.
Em outras palavras, a pergunta deixa de ser “Há capital suficiente do outro lado?”
E passa a ser “O sistema consegue provar com certeza que a oferta foi destruída antes que uma nova oferta apareça em outro lugar?”
Isso parece menos um problema de liquidez e mais um problema de coordenação e finalidade.
Estou curioso sobre como a Dusk lida com casos extremos em que um lado atinge a confirmação final, mas a cunhagem correspondente permanece atrasada ou é interrompida.
#dusk @Dusk $DUSK
A maioria das pontes depende de liquidez que fica em algum lugar, esperando para facilitar as transferências. Isso funciona até que a liquidez se torne escassa, fragmentada ou dependa de um pequeno conjunto de atores se comportando como esperado.
O modelo CCT da Dusk segue um caminho diferente. Em vez de passar por um pool, o ativo é removido de circulação em uma cadeia e recriado em outra por meio de um processo de queima e cunhagem.
O tradeoff é interessante.
Você não depende de liquidez disponível nem precisa se preocupar com slippage. Mas isso não torna o sistema isento de riscos. A hipótese crítica muda para saber se o evento de queima é verificado corretamente e se o processo de cunhagem é executado conforme o pretendido entre as cadeias.
Em outras palavras, a pergunta deixa de ser “Há capital suficiente do outro lado?”
E passa a ser “O sistema consegue provar com certeza que a oferta foi destruída antes que uma nova oferta apareça em outro lugar?”
Isso parece menos um problema de liquidez e mais um problema de coordenação e finalidade.
Estou curioso sobre como a Dusk lida com casos extremos em que um lado atinge a confirmação final, mas a cunhagem correspondente permanece atrasada ou é interrompida.
#dusk @Dusk $DUSK