O Oracle abaixo foi projetado para ser uma maneira minimizada e sem permissão de obter preços de token que qualquer um pode usar.
Em seu nível mais básico, o Oracle funciona fazendo com que um repórter envie um lance de limite e peça pelo mesmo preço. Qualquer pessoa pode trocar por essas ordens menos uma pequena taxa (sem preenchimentos parciais). Se ninguém tomar qualquer um dos pedidos em um certo período de tempo, é uma evidência de um bom preço que pode ser usado para liquidação. Se um pedido for realizado, o tomador precisará publicar garantias em ambos os tokens, implica um novo preço e o timer reinicia.
O Oracle usa a escalada colateral exponencial durante as disputas para aumentar o custo da manipulação e dar aos usuários algumas garantias estatísticas em torno do tempo total para liquidação e custo para atrasar. No caso médio, o capital necessário para relatar preços precisos pode ser muito menor do que o valor nocional liquidado pelo preço relatado. O objetivo é substituir o conjunto atual de intermediários centralizados e confiáveis, para que os aplicativos defi possam ter menos pontos de falha.
O design depende de 1 de N participantes interessados em auto-telas que não estão economicamente alinhados com a posição externa sendo estabelecida pelo Oracle com sua transação incluída antes do prazo.
Uma das limitações claras do projeto é a censura (envie um preço ruim → disputas censuradas → lucro). Isso coloca um limite difícil de quanto o Oracle pode proteger em L2 e, até o focil, devemos usar tempos de liquidação mais longos no L1 para reduzir a chance de um invasor controlar muitos blocos seguidos.
Abaixo está um exemplo simplificado do ciclo de vida do Oracle:
Digamos que um aplicativo deseja o preço do Weth contra o USDC. Na solicitação de preço, eles especificam
- Token1: Weth
- Token2: USDC
- Token1Amount: 0.1 Weth
- Tempo de liquidação: 10 segundos
- Multiplicador: 1.5x
- Recompensa: 0,001 ETH
O saldo do contrato Oracle agora é 0,001 ETH.
Essa solicitação de preço fica na cadeia e qualquer pessoa pode relatar um preço. Digamos que o preço do ETH seja de US $ 3000. O próximo passo é que um repórter envia um relatório inicial, vencendo a corrida contra todos os outros para reivindicar o 0,001 ETH.
Como um aplicativo estava usando o Oracle para obter um preço, assumiremos que há duas pessoas em posições opostas. Ou seja, se o preço for mais alto, uma pessoa se beneficia e a outra perde e vice -versa. Suponha que uma das pessoas seja completamente passiva, mas assuma que o outro está ativo e se beneficiaria se o oráculo de liquidar relatando Weth como não tão valioso. Portanto, assuma que o repórter inicial é o manipulador nesta parte, porque eles são capazes de superar todos os outros no bloco.
No relatório inicial, eles especificam:
Token1Amount: 0.1 Weth
token2amount: 150 USDC
Os saldos do contrato Oracle são agora 0,001 ETH, 0,1 WETH e 150 USDC.
Esses saldos do relatório implicam um preço ETH de US $ 1500 quando o preço real é de US $ 3000.
Após o tempo de liquidação de 10 segundos, assumindo que ninguém contesta este relatório, o relatório pode ser resolvido e se tornar utilizável para o pedido, a um preço horrível. Mas, é lucrativo aparecer e contestar isso, por isso assumimos que um disputador aparece antes que 10 segundos subissem.
Na disputa, eles especificam:
Token1AmountNew: 0.15 Weth
Token2amountNew: 450 USDC
TokentoSwap: USDC
Eles decidem trocar contra os 150 USDC do repórter inicial, o que significa que eles escolhem o USDC como o token para trocar em sua disputa. O Token1AmountNew é 50% maior que o relatório inicial por regra do contrato usando o multiplicador de 1,5x da solicitação de preço. Os fluxos de token são os seguintes:
O contrato da Oracle recebe 150 USDC do disputador e adiciona isso ao 150 USDC original do repórter inicial e envia tudo ao repórter inicial, para um total de 300 USDC enviado ao repórter inicial.
Em seguida, o contrato Oracle pega 450 USDC e 0,05 Weth do disputador e o adiciona ao relatório.
Os saldos do contrato são agora 0,001 ETH, 0,15 Weth e 450 USDC e o timer de tempo de liquidação é redefinido para mais 10 segundos.
Suponha que o manipulador cede e o tempo de liquidação de 10 segundos passes, qualquer um pode aparecer e resolver o preço relatado. O preço do Oracle é de US $ 3000, enquanto o preço real é de US $ 3000.
No acordo, o colono especifica apenas quais relatam que estão liquidando. Normalmente, eles recebem alguma recompensa de colono na ETH paga pelo solicitante de preços, mas assumimos 0 para este exemplo. Os fluxos de token no acordo são os seguintes:
O repórter inicial (o manipulador) recebe 0,001 ETH da recompensa inicial do repórter. Isso deve ser realizado contra o custo do gás de superar todos os outros para ser o primeiro repórter inicial.
O disputador recebe 450 USDC e 0,15 Weth de volta.
Os saldos do contrato estão agora 0 em todos os tokens de ETH. Se reduzirmos os fluxos em todo o ciclo de vida do Oracle de solicitação de preço, relatório inicial, disputa e liquidação, vemos o seguinte:
Repórter inicial:
USDC: +150
Weth: -0.1
Disputador:
USDC: -150
Weth: +0.1
Suponha que as taxas de gás e a recompensa inicial do repórter sejam quase zero. O preço verdadeiro do ETH é de US $ 3000, então o manipulador perde US $ 150, o disputa ganha US $ 150 e o preço do Oracle se acalma de maneira justa para que o pedido seja usado. Se o manipulador decidisse continuar tentando manipular o preço disputando o relatório do disputador honesto, eles perderiam uma quantia exponencialmente crescente de dinheiro que escala com o erro no preço relatado.
A implementação do Oracle de referência em solidez tem mais parâmetros para ajustar, como taxas de troca, interrupção da escalada, atraso de disputa, modo de tempo (segundos versus blocos) e muito mais, mas a versão simplificada é precisa em relação à maneira como os incentivos funcionam.
As taxas de troca são um parâmetro importante para uma determinada instância do Oracle. Um novo repórter paga ao repórter anterior uma taxa de troca em %, que é definida no momento da solicitação de preço. Se as taxas de swap forem muito baixas em relação à volatilidade do mercado de fundo sobre o tempo de liquidação especificado, o tempo total para a liquidação poderá se arrastar à medida que as contas a redefinição do timer são mais comuns. Se as taxas de troca forem muito altas, por outro lado, isso expõe usuários passivos do preço do Oracle para a perda de arbitragem, porque um manipulador ativo pode tentar obter o preço para se estabelecer em algum lugar dentro da taxa de troca vinculada, mas longe do preço verdadeiro.
Portanto, há uma troca fundamental entre o tempo total de finalização da Oracle Instância e a perda de arbitragem para os usuários finais.
Em termos da perda máxima de arbitragem a que um usuário final completamente passivo é exposto, esse número é estritamente menor que o total de taxas de troca Oracle interno por rodada mais taxas de gás mais perda de salto para o repórter. Chamamos isso de uma taxa de troca eficaz F (swap_fees + gas_fees + jump_loss). Assumimos que, se o preço estivesse fora de F, seria contestado por 1 de n participantes de interesse próprio. Como apenas o preço final sobrevivente contribui para o erro de preço em um nocional externo, o valor total extraível é <= F. Isso se aplica apenas a nocionais externos lineares. O nocional externo binário é mais complicado, pois não há nenhuma obrigação de perda de arbitragem, mas pode -se imaginar uma instância do Oracle parametrizada para punir atrasos nos acordos especialmente difícil se precisarmos resolver apostas binárias.
A perda de salto é um custo para os repórteres, independentemente da direção que o preço se move. Os preços do token podem interromper descontínuo e o repórter consomem a diferença em comparação com a taxa de troca independente depois que alguém disputa e corrige o preço. Multiplicadores mais altos sobrecarregar os repórteres com mais perda de salto por rodada em relação ao erro de preço natural do relatório anterior.
A interrupção da escalada é outro parâmetro importante. Após essa parada, as disputas podem continuar, mas não precisam mais postar quantidades exponencialmente crescentes de garantia. Dessa forma, você pode garantir que a instância do Oracle não aumente a capacidade percebida da rede de disputas, enquanto ainda imponha altas penalidades aos manipuladores.
A implementação completa da solidez pode ser encontrada abaixo. Nota As entradas de função direta podem ser complementadas com guardas de reorganização / reprodução de contrato externo (ou seja, se o TX não passar o número do bloco passado e a reversão do registro de data e hora ou a liquidação deverá usar o preço de solicitação de preço correspondente), o que pode ajudar, mas não eliminar o risco.
Adoraria ouvir qualquer feedback ou crítica sobre o design e fico feliz em responder a quaisquer perguntas! Esperamos contribuir para o desenvolvimento de aplicativos financeiros verdadeiramente sem confiança.
Fontesethresear
