Protocolo de troca de trava relâmpago da camada Mercury

0
56

Commerceblock lançou um novo protocolo de troca atômica para uso com statechains em seu protocolo Mercury Layer. O servidor HSM introduziu funcionalidade para suportar a troca atômica de duas cadeias de estado, bem como impor uma troca atômica de uma cadeia de estados por um pagamento Lightning. Este é o primeiro exemplo de interações concretamente definidas e construídas entre statechains e a Lightning Network. A sinergia entre os dois protocolos foi postulada desde que o conceito de statechain foi originalmente proposto por Ruben Somsen, especificamente como uma forma de resolver a limitação de ter que transferir toda uma statechain UTXO de uma só vez.

Trocas básicas de cadeia de estado

Para suportar os novos protocolos de troca, o servidor HSM precisa adicionar alguns novos campos às entradas do banco de dados, rastreando cada cadeia de estado que está facilitando. Para facilitar a troca de statechain para statechain, o servidor precisa rastrear:

  • Batch_id: um valor para associar statechains sendo trocados em um grupo.
  • Tempo de lote: um tempo que inicia um contador após o qual as cadeias de estado podem ser “recuperadas” se a troca falhar.
  • Bloqueado: um valor que indica se a cadeia de estado está ou não bloqueada e restrita para transferências regulares.

Isso permite que o servidor HSM rastreie e aplique todas as variáveis ​​necessárias para garantir uma troca atômica segura. Ao iniciar uma troca, os usuários devem se comunicar diretamente entre si para estabelecer um batch_id compartilhado entre eles. A partir deste ponto, eles negociam todas as informações necessárias para facilitar uma transferência normal da cadeia de estado e enviam essas informações mais o batch_id e o horário do lote para o servidor. Essencialmente, eles iniciam o processo de transferência regular, mas também anexam as variáveis ​​para conectar as cadeias de estado individuais como participantes de uma troca e quanto tempo dura o período de tempo limite para isso.

O servidor neste ponto aplicará um bloqueio a cada statechain usando o mesmo batch_id no processo de transferência. Até que o tempo limite expire ou todas as cadeias de estado em seu banco de dados usando o mesmo batch_id tenham sido desbloqueadas pelos proprietários atuais, o servidor não aprovará nenhuma transferência. Uma coisa interessante sobre a maneira como o HSM impõe a lógica de troca é que não importa quem entra em contato com o servidor primeiro. Quando o servidor recebe uma mensagem usando um batch_id, ele verifica cada statechain em seu banco de dados e se existe um tempo de lote pré-existente para esse batch_id ele o define como o mesmo. Isso garante que não importa quem registre a troca primeiro, todos usem o mesmo valor de tempo para a função de tempo limite.

Cada cliente envolvido na troca neste ponto verifica e baixa as mensagens que iniciaram o protocolo de transferência e, ao verificar se estão corretas, envia uma mensagem ao servidor para desbloquear seu statechain, removendo as restrições de transferência. Sempre que alguém tenta finalizar uma transferência no lado do receptor de qualquer uma das statechains envolvidas na troca, o servidor verifica se todas as statechains com o mesmo batch_id estão desbloqueadas. Se mesmo um único com o batch_id relacionado ainda estiver bloqueado, o servidor não finalizará a transferência para nenhum deles. Se uma troca não for bem-sucedida antes do tempo limite, o servidor continuará restringindo a finalização da transferência de troca, mas permitirá que os atuais proprietários inicializem uma nova transferência para si mesmos para cancelar efetivamente a troca.

Trava relâmpago

A funcionalidade Lightning Latch, trocando um statechain por um pagamento Lightning, funciona de forma muito semelhante à troca de statechain para statechain. Aqui estão os novos campos que o servidor deve rastrear para a troca do Lightning:

  • Batch_id: um valor para associar statechains sendo trocados em um grupo.
  • Tempo de lote: um tempo que inicia um contador após o qual as cadeias de estado podem ser “recuperadas” se a troca falhar.
  • Pré-imagem: a pré-imagem do pagamento Lightning, que é gerada pelo servidor HSM.
  • Locked_1 e bloqueado_2: existem dois campos de bloqueio para o Lightning swap, um autorizado por cada usuário envolvido.

Assim como acontece com a troca de statechain para statechain, os usuários estabelecem e compartilham um batch_id aleatório. O proprietário atual do statechain então envia uma mensagem ao servidor com o batch_id e o statechain envolvidos e solicita que ele gere uma pré-imagem de hashlock para um pagamento Lightning. Esse usuário então gera uma fatura Lightning usando essa pré-imagem, e o segundo usuário entra em contato com o servidor para confirmar que gerou a pré-imagem. O atual proprietário do statechain inicia o processo de transferência do statechain e carrega a mensagem de transferência para o servidor.

Após a confirmação disso, o segundo usuário que tenta trocar pelo statechain inicia o pagamento Lightning. Neste momento o servidor é o único com a pré-imagem, portanto o proprietário do statechain ainda não pode finalizar o pagamento. O proprietário atual, após verificar o pagamento pendente do Lighting, envia ao servidor uma mensagem de desbloqueio para remover o primeiro bloqueio no statechain. O receptor finalmente verifica a mensagem de transferência e, se as mensagens forem válidas, o servidor também remove seu bloqueio.

Agora, com ambos os bloqueios removidos, o servidor HSM liberará a pré-imagem para o atual proprietário do statechain para finalizar o pagamento do Lightning e finalizará a transferência do statechain para o destinatário.

Este esquema exige confiança no operador da cadeia de estado para funcionar honestamente, mas isso não é fundamentalmente uma mudança no modelo de confiança pré-existente de utilização de uma cadeia de estado em geral. Em nenhum momento a operadora tem controle sobre os fundos dos usuários, nem aprende nada sobre os detalhes de pagamento do Lightning.

Para que serve isso?

Este esquema está muito longe da interação originalmente postulada entre statechains e canais Lightning, empilhando um em cima do outro, mas mesmo como um simples ponto de partida, apresenta utilidade funcional para usuários existentes do Lightning. O reequilíbrio de canais é algo necessário para muitos nós; se a capacidade for totalmente empurrada para um lado ou outro, a utilidade desse canal será limitada para rotear pagamentos. Muitas empresas e usuários começaram a experimentar o uso do Liquid como um mecanismo para isso devido ao aumento das taxas na rede e ao aumento do custo das trocas dentro e fora da Lightning Network.

Statechains oferecem um mecanismo alternativo a uma sidechain federada para aliviar algumas das despesas de taxas associadas ao gerenciamento do saldo do canal. Em vez de ter que trocar diretamente para a cadeia principal ou usar uma cadeia lateral, os fundos podem ser trocados para uma cadeia estatal e mantidos lá até que sejam necessários para a troca de fundos de volta a um canal. Economias semelhantes em taxas podem ser obtidas, mantendo a capacidade de reivindicar unilateralmente seus fundos na rede principal.

Outro caso de uso potencial (TRIGGER WARNING) seria a possibilidade de mercados mais eficientes para negociação de ordinais. Como os ordinais são simplesmente um esquema de índice que rastreia caminhos retroativos no histórico de transações para satoshis específicos, eles podem ser facilmente retirados da cadeia para uma cadeia de estado. Essa dinâmica em combinação com o Lightning Latch poderia permitir compras de ordinais fora da rede mais baratas e rápidas. Alguém poderia construir um mercado onde eles pudessem ser vendidos instantaneamente fora da rede pela Lightning Network.

É até possível um dia se os clientes do Lightning pudessem tomar conhecimento de alguma forma de quais operadores de statechain específicos dos nós do Lightning confiam que o Latch poderia ser usado para ajudar a rotear pagamentos, passando statechains entre diferentes nós, em vez de usar canais convencionais do Lightning.

Na frente das transferências puras de statechain para statechain, isso oferece o potencial para uma camada de passagem de mensagens para recriar coinjoin como um sistema de mistura de moedas fora da cadeia, semelhante à funcionalidade de mistura original na primeira implementação de statechain do Commerceblock.

Embora seja um ponto de partida muito simples, o Lightning Latch e a funcionalidade de troca de statechain abrem a primeira porta de integração de statechains na Lightning Network existente – e outras camadas semelhantes que virão no futuro – de uma forma que permite que todos eles se integrem perfeitamente e funcionar como uma rede singular em termos de roteamento de pagamentos e gestão de liquidez. Mesmo enquanto debatemos a necessidade e a utilidade dos convénios, ainda há muito espaço para continuar a construir com o que já temos.

Você pode ouvir a equipe do Commerceblock explicar a lógica além do protocolo aqui:

https://platform.twitter.com/widgets.js

E para uma explicação mais técnica, aqui:

https://platform.twitter.com/widgets.js

Fonte: bitcoinmagazine.com

Receba nossas atualizações
Fique por dentro de todas as notícias e novidades do mundo da tecnologia!

ARTIGOS RELACIONADOSMais do autor

Deixe uma resposta