Para que o esquema se torne infraestrutura, é essencial abstrair um modelo de negócios geral dos requisitos reais, incluindo requisitos de transferência de cadeia cruzada do mesmo token, tokens diferentes e NFT.
O mundo da Orbiter compreende duas partes: o remetente inicia os eventos na rede iniciante e nos eventos que respondem na rede de destino.
A missão do Orbiter é garantir que esses dois eventos ocorram em uníssono.
Como o Orbiter completa o processo?
R. Para fazer com que os remetentes se sintam seguros para iniciar eventos, os fabricantes prometem margem suficiente no contrato do MDC na cadeia para responder ao evento.
B. Se o fabricante não responder ao evento iniciado pelo remetente prometido, o remetente deve enviar uma solicitação de arbitragem ao contrato do MDC e fornecer prova de evento iniciante.
C. Se o fabricante não fornecer contrato com o MDC com prova de evento de resposta dentro do tempo especificado, o contrato da MDC compensará o remetente com a margem do fabricante.
O sistema da Orbiter contém três contratos e módulos:
MDC （Contrato de depósito do fabricante)
O MDC possui duas funções principais: mantendo a margem do fabricante, a resolução de disputas e o manuseio de ativos de retorno e compensação.
EBC (contratos de ligação a eventos)
O EBC é usado para calcular o TX de destino válido correspondente com base no TX de origem.
Cliente de luz SPV.
O SPV prova que a fonte do TX ocorreu na rede de origem.
Esses três contratos e módulos são executados na cadeia X, que pode ser qualquer ambiente de suporte de contrato inteligente no sistema Ethereum, na Ethereum Mainnet, quaisquer rollups ou até rede de origem ou rede de destino, desde que a cadeia mantenha contratos inteligentes.
Os três módulos de contrato funcionam juntos assim:
O fabricante pode oferecer suporte aos requisitos de transferência cruzada do remetente do remetente após depositar uma margem no contrato do MDC.
No processo de transferência correto normal, depois que um TX de origem é gerado na rede de origem, o EBC calcula o TX de destino que atende aos requisitos de acordo com o TX de origem. O fabricante envia o Target TX para a rede de destino para concluir uma transferência cruzada.
Mas quando o fabricante não envia o Target TX a tempo, o remetente deve fornecer comprovante de origem TX ao SPV na cadeia X e solicita arbitragem ao contrato do MDC. O MDC obtém a prova de ocorrência de TX de origem através do SPV, obtém a prova de validade TX de origem por meio do EBC, define a solicitação de arbitragem como um evento não processado e aguarda o fabricante de enviar a prova TX TVOL. Suponha que o fabricante não forneça à prova de TX do destino imediatamente. Nesse caso, o MDC iniciará o processo de compensação, retornará ativos e enviará compensação ao remetente na cadeia X com a margem do fabricante.
O que é o MDC?
O MDC (contrato de depósito do fabricante) é um contrato de armazenamento para margem, que especifica uma lógica de processo de arbitragem comum. O fabricante pré-despoja a margem no contrato do MDC e bloqueará uma margem suficiente para fazer uma transferência específica de rollop cruzada (contrato de ligação a eventos, ambiente e moeda) para garantir que o remetente possa ser compensado em um caso adverso.
Como o MDC lida com a arbitragem？
Os procedimentos de arbitragem serão iniciados quando todas as seguintes condições ocorrerem.
Após a conclusão de todo o processo de arbitragem, o remetente receberá ativos de volta e compensação.
Orbiter lê o valor de hash válido registrado por duas redes na rede principal como base para a arbitragem.
As seguintes condições devem tomar a decisão do remetente:
Antes que o remetente decida transferir, ele só precisa conhecer a condição de operação do endereço do fabricante correspondente a outras transferências para ver a capacidade do fabricante e escolher se deve ser transferido.
Estamos desenvolvendo um módulo SPV e será de código aberto quando o concluirmos. Atualmente, o estado é:
Eles serão implantados em cerca de dois meses.
