MasterChef Smart Contracts: as soluções para defeitos fatais

MasterChef Smart Contracts: as soluções para defeitos fatais

O MasterChef possui algumas falhas que podem ser corrigidas durante o uso, mas somente se os usuários estiverem cientes delas e do que podem fazer. Aqui está a solução alternativa, de acordo com Gleb Zykov e Vlad Korovnikov da HashEx .

As exchanges descentralizadas (DEXs) eram bastante raras há apenas dois anos, mas parecem estar em toda parte hoje. Numerosos projetos com suas próprias DEXs pessoais. Isso aconteceu porque, quando um projeto de blockchain decide lançar um DEX, ele não o faz completamente do zero. Em vez disso, a base para o código DEX geralmente é uma bifurcação de uma das duas DEXs principais: SushiSwap ou PancakeSwap.

Contrato Inteligente Masterchef

Essas duas exchanges praticamente revolucionaram o espaço DEX graças a um contrato inteligente especial chamado MasterChef. MasterChef aparece em ambos e, portanto, também aparece em qualquer DEX criada como um fork de qualquer um desses dois. Cada nova DEX compartilha as mesmas características. Mas também significa que compartilha as deficiências e vulnerabilidades do MasterChef.

Então, vamos dar uma olhada em quais problemas os usuários e desenvolvedores podem encontrar ao lidar com o MasterChef. O que eles devem prestar atenção? E como eles devem ser abordados?

Como funcionam as DEXs?

A primeira coisa a notar é que um contrato MasterChef é um contrato inteligente escrito em Solidity que controla o que uma fazenda pode fazer e como pode fazê-lo. Na maioria dos projetos, existem vários contratos inteligentes que compartilham a responsabilidade e o trabalho. Mas quando se trata de protocolos baseados no MasterChef, é esse contrato exclusivo que cuida de tudo relacionado à agricultura.

As exchanges descentralizadas permitem que você negocie criptomoedas sem ter que depositar dinheiro na carteira da exchange. Em vez disso, você deposita fundos em contratos inteligentes da sua carteira. Você é a única pessoa que o controla e pode acessar seus fundos se os contratos não tiverem backdoors ou vulnerabilidades.

Outra diferença é que os CEXs usam livros de pedidos para compra e venda. Isso significa que eles combinam compradores e vendedores, enquanto os DEXs usam protocolos Automated Market Maker (AMM) para negociação, que calcula o preço dos ativos com base na quantidade de liquidez investida.

A liquidez vem de pools de liquidez, que são pools onde os usuários podem depositar fundos para pares específicos e disponibilizar fundos para o protocolo. Então, quando alguém tenta comprar ativos usando esse par, seu pedido é imediatamente atendido usando os fundos do pool. Enquanto isso, as pessoas que depositaram fundos no pool de liquidez obtêm tokens LP para esse pool específico. Isso lhes dá o direito de compartilhar as recompensas.

E, se eles quiserem recuperar seus fundos, tudo o que precisam fazer é devolver os tokens LP que receberam.

Como você deve saber, existem várias maneiras de gerar retornos de ativos de criptomoedas. As fazendas oferecem recompensas adicionais por fornecer liquidez. Os usuários adicionam liquidez aos DEXs, obtêm tokens LP e os apostam em fazendas.

MasterChef: Vulnerabilidades e defeitos

Explicamos como funcionam as DEXs e como funcionam os pools de liquidez. Então, vamos dar uma olhada em onde as vulnerabilidades do MasterChef entram em jogo, como elas afetam o processo e qual abordagem você precisa adotar para garantir que as coisas corram bem.

MasterChef é um único contrato inteligente usado para rendimento agrícola, fornecendo liquidez em DEX. Infelizmente, ele possui algumas falhas que podem ser corrigidas durante o uso, mas somente se os usuários estiverem cientes delas e do que podem fazer.

Contas comprometidas

Um dos maiores problemas a serem observados gira em torno do comprometimento das contas dos proprietários. Basicamente, o SushiSwap criou um método que lhe permitiu ganhar vantagem contra o Uniswap. Esse método gira em torno da migração de ativos de uma exchange para outra. Isso é tratado pelo contrato usando uma função separada acessível apenas pelo titular do contrato.

No entanto, essa migração pode acabar sendo ajustada para praticamente qualquer contrato, sem limite, o que se mostrou um grande descuido. Portanto, se a conta do proprietário for comprometida, isso pode resultar em um novo contrato de migração que enviaria todos os tokens LP básicos em todos os grupos de reprodução para um endereço arbitrário. Isso resultaria em uma perda maciça de ativos investidos.

Deve-se notar que esse recurso agora é familiar aos desenvolvedores e, portanto, acaba sendo removido imediatamente nos forks. No entanto, se permanecer presente, deve ser imediatamente considerado como uma bandeira vermelha.

Outra coisa a notar é que, em alguns forks do MasterChef, o titular do contrato pode alterar a taxa de emissão sem qualquer limite. Se a conta for comprometida, no entanto, um invasor pode definir uma taxa de emissão muito alta, o que levaria à desvalorização do token.

Existe uma maneira bastante simples de resolver esse problema, simplesmente garantindo que todos os recursos disponíveis para o proprietário do contrato exijam autorização com várias assinaturas. Dessa forma, se um único endereço for comprometido, os bandidos não poderão fazer muito a respeito. Outra coisa a fazer é adicionar um bloqueio temporário (contrato Timelock) à chamada da função de migração. Dessa forma, o usuário tem mais tempo para tomar uma decisão, e a exchange deverá notificá-lo sobre a migração ou qualquer outra transação suspeita.

Adição de piscinas agrícolas idênticas

Outro problema bastante óbvio, mas negligenciado, surge quando o contrato original não leva em consideração a criação de grupos de reprodução idênticos, o que significa que o contrato ameaça calcular mal os prêmios de reprodução.

Isso não é grande coisa se o MasterChef for usado corretamente, pois o proprietário não adicionaria propositalmente pools idênticos. De fato, em trocas que funcionam corretamente, essas coisas são verificadas e é fortemente proibido criar um pool duplicado. Portanto, se você começar a criar o pool e estiver indo para a criação de uma duplicata do pool existente, o sistema poderá relatar um erro. Ou sugira adicionar seus fundos ao pool existente em vez de criar um novo.

Não calcular a quantidade de tokens depositados

Por alguma razão, as pessoas tendem a esquecer de considerar o que poderia acontecer se tokens com taxas de transferência ou tokens de rebase fossem adicionados como um pool ao contrato MasterChef. O que acontece é uma interrupção na forma como as recompensas são calculadas, pois o código do contrato apenas adiciona recursos aos pools chamando determinadas funções. Isso significa que adicionar tokens ao endereço os combinará com ativos já no pool. Mas os cálculos das recompensas desses tokens podem ser interrompidos, o que leva a vulnerabilidades.

As plataformas em operação adequada devem calcular separadamente o valor dos fundos transferidos para a agricultura, verificando o valor real transferido que leva em consideração as taxas. Desta forma, os cálculos de recompensa são realizados corretamente.

MasterChef: Conclusão

MasterChef é um único contrato inteligente usado para rendimento agrícola, fornecendo liquidez em DEX. Infelizmente, ele possui algumas falhas que podem ser corrigidas durante o uso, mas somente se os usuários estiverem cientes delas e do que podem fazer.

Acima, cobrimos várias coisas que podem acontecer e como esses problemas podem ser evitados. Mas vale ressaltar que existem outros, como a diluição das recompensas caso os tokens sejam enviados diretamente para o endereço do contrato, problemas com alterações de blocos de inicialização, otimizações de gás e muito mais.

Em outras palavras, há vulnerabilidades e problemas a serem lembrados e observados. Mas, no geral, o MasterChef é um contrato revolucionário que praticamente permitiu o comércio descentralizado. Portanto, desde que você continue a usá-lo com cuidado e esteja ciente de suas falhas e de como corrigi-las, você deve ficar bem.

sobre os autores

Gleb Zykov

Gleb Zykov é cofundador e CTO de uma empresa de segurança e análise DeFi HashEx .

Vlad Korovnikov é o revisor e desenvolvedor do Junior Smart Contract.

Você tem algo a dizer sobre as soluções alternativas do Masterchef ou outro? Escreva para nós ou participe da discussão em nosso canal do Telegram. Você também pode nos encontrar no Tik Tok , Facebook ou Twitter .

O post MasterChef Smart Contracts: The Workarounds for the Fatal Flaws apareceu pela primeira vez no BeInCrypto .