Muitos agradecimentos a Anders Elowsson pelas discussões iniciais que provocaram essa série de postagens e pelos seus muitos comentários úteis sobre o texto. Agradeço também a Caspar Schwarz-Schilling, Julian Ma, Thomas Thiery, Davide Crapis, Mike Neuder, Drew Van der Werff, Kydo e muitos outros pelas discussões e comentários sobre o texto. Foto da capa por @pawel_czerwinski?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Pawel Czerwinski on Unsplash.

Staking, re-staking, liquidez staking, re-staking líquido, tokens re-estacados de staking líquido, operadores de nó e provedores de capital… Observamos desde o lançamento da Beacon Chain em dezembro de 2020 uma coleção cada vez mais variada de mecanismos e construções, começando pelo próprio mecanismo de staking do protocolo.

Nas discussões dentro de nossa equipe, sentimos a necessidade de uma linguagem precisa que nos permita eliminar ambiguidades em relação à arquitetura desses mecanismos. Esperamos enfatizar a existência de pontos de controle e desalinhamentos de incentivos por meio do uso de notação e balanços, já que nuances são muito importantes para destacar adequadamente as oportunidades e riscos. O exercício foi feito principalmente para a nossa própria compreensão, mas, ao passarmos por ele, sentimos que proporcionou uma maneira útil de agregar uma coleção de fatos e discussões díspares em uma abordagem coerente e sistemática.

Neste post e nos dois próximos, apresentamos essas construções juntamente com estudos de caso. Não temos como objetivo uma revisão exaustiva de todo o material produzido por todas as equipes brilhantes que trabalham nessas mecânicas, e pretendemos que nossa semântica seja atualizada conforme necessário sempre que novos fatos revelarem lacunas ou erros em nossos modelos.

1. Parte 1: Liquefação
2. Parte 2: Re-staking
3. Parte 3: Conjuntos de construção avançados para maiores de 16 anos

A série atual de postagens também não chega a conclusões sobre a otimalidade ou o uso dessas construções, além de fornecer definições e contexto para sua existência. Postagens futuras abordarão essas questões e oferecerão propriedades desses mecanismos, como sua utilidade para várias classes de stakers e sua economia em um contexto maior.

Vamos nessa!

Ativo

O “tipo” mais básico de nossa semântica é o de um ativo. Um ativo pode ser tokens nativos de uma blockchain descentralizada, como ETH, tokens enraizados em alguma blockchain como ERC-20s ou NFTs, ou ativos construídos a partir de outros ativos, como derivativos são.

Balancetes

A seguir, ilustramos nossas construções com balanços patrimoniais mostrando a criação e transferência de ativos entre múltiplas partes envolvidas. Sempre fornecemos os balanços patrimoniais no mesmo formato:

1. A primeira linha representa o "pré-estado", denotando quais ativos são atualmente de propriedade de cada parte.
2. A última linha representa o “pós-estado”, denotando quais ativos são de propriedade de cada parte depois que todas as operações foram concluídas.
3. As linhas intermediárias representam operações, sendo que uma nova linha simplesmente denota um novo conjunto de operações, separado dos outros com o propósito de exposição.

Nós usamos duas operações básicas repetidamente, que valem a pena detalhar aqui:

1. Transferência de ativos: A Parte A simplesmente transfere alguns Ativos para a Parte B.

1. Emissão de recibo: frequentemente representamos situações em que a Parte A recebe uma reivindicação da Parte B, permitindo que a Parte A resgate alguns ativos da Parte B. O recibo se torna então uma responsabilidade para a Parte B e um ativo para a Parte A. No exemplo a seguir, a Parte A transfere um Ativo para a Parte B e recebe uma Reivindicação da Parte B.

Não usamos balanços de forma muito ortodoxa, sendo mais inspirados pelo Economia do Dinheiro e Bancoscurso, bem como de Daniel H. Neilson.Em breve partedboletim informativo (enquanto declara para o registro que provavelmente não somos tão rigorosos quanto eles). No entanto, acreditamos que este conjunto mínimo de operações é suficiente para fornecer a intuição necessária.

Protocolo de staking

Staker individual

A primeira operação básica consiste em colocar ETH em jogo no protocolo Ethereum Proof-of-Stake. No caso mais simples, um detentor de ETH coloca seu ETH diretamente no protocolo, recebendo um saldo 'virtual' de soETH (o 'so' significa operador solo). Representamos a relação com as seguintes demonstrações de saldo, que são lidas linha por linha entre as várias partes:

O staker solo é responsável pelas operações de seu validador correspondente. Isso significa que se o staker solo desempenhar adequadamente suas funções de consenso, o protocolo Ethereum credita seu saldo de soETH com novo soETH. Por outro lado, quando o staker solo recebe penalidades ou é punido, o protocolo debita seu saldo de soETH. Quando o staker solo deseja sacar seu saldo de soETH e obter ETH, a retirada é processada 1:1, ou seja, para x unidades de soETH no saldo de consenso do validador, o staker solo recebe x ETH em troca (no caso de uma retirada total).

Observe que não representamos recompensas da “camada de execução”, por exemplo, taxas de prioridade e MEV. Essas recompensas são uma adição direta ao modelo apresentado acima, e constituem uma simples transferência de ETH das partes na camada de execução para o staker solo assumindo os deveres de produtor de blocos.

Usando um Provedor de Serviço de Staking (SSP)

Uma relação mais complexa está em jogo quando um Provedor de Serviço de Stake (SSP) intermedia a relação entre o detentor que deseja fazer stake (”delegador”) e o protocolo Ethereum. Neste caso, o detentor de ETH primeiro fornece ao SSP ETH nativo com o propósito de que ele seja staked. O SSP faz o stake do ETH e recebe controle sobre o ativo “soETH” em execução na camada de validação. Ele confere um ativo virtual noETH ao delegador (o “no” significa operador de nó), contra o qual seu ETH em stake é resgatável.

Nosso uso da palavra "resgatável" já introduz alguma incerteza aqui. Como vimos acima, o protocolo Ethereum permite que o staker solo retire seu saldo de soETH contra ETH na paridade. Isso também é verdade para o staker que delega seu ETH para o SSP em troca de noETH? Em geral, isso não é verdade. Primeiro, 1 noETH poderia resgatar menos de 1 soETH, se a redução ocorresse. Segundo, como a maioria dos SSPs fornece seu serviço contra uma taxa, 1 noETH resgata uma fração do soETH creditado na conta do SSP em excesso do seu principal em jogo. Uma demonstração de resultado mais precisa separaria o principal do rendimento, por exemplo:

Aqui, nós “desmembramos” o ativo soETH entre o principal pETH e o rendimento yETH. pETH resgata no máximo 32 ETH, a menos que ocorra penalização. yETH resgata as recompensas da camada de consenso e da camada de execução obtidas pelo SSP. O SSP fornece reivindicações correspondentes ao delegante, no.pETH e no.yETH. O delegante sempre pode receber seu principal integralmente, incluindo as penalizações, de modo que exista uma taxa de câmbio de 1:1 entre no.pETH e pETH. No entanto, uma taxa é cobrada pelo SSP, de modo que a taxa de câmbio entre no.yETH e yETH é inferior a 1 (1 no.yETH resgata menos que 1 yETH). Desmembrar o ativo pode ser útil em alguns lugares, mas também introduz complexidades adicionais que não são críticas para as seções seguintes, então continuamos usando soETH e noETH para representar toda a reivindicação.

Outra consideração é se o SSP agrupa ou não o ETH de seus depositantes.

1. Sem pooling: Um SSP abre vários pools paralelos, um para cada depositante. Suponha que os depositantes A e B forneçam seu ETH ao SSP, que abre os validadores A e B, um para cada depositante. Suponha então que o validador A seja punido pela metade de seu depósito, enquanto o validador B não é. Neste caso, o depositante A pode retirar seu ETH em jogo a uma taxa de 1:0,5 (1 parte de noETH resgata 0,5 partes de ETH em jogo), enquanto o depositante B pode retirar seu ETH a uma taxa de 1:1 (módulo taxas). É então incorreto falar de um único noETH, pois na prática existem noETH-A e noETH-B que representam reivindicações diferentes.
2. Pooling: O protocolo Ethereum requer unidades de 32 ETH a serem colocadas em jogo, o que significa que se os depositantes A e B quisessem apostar apenas 16 ETH cada, não poderiam fazer isso com a construção detalhada no ponto anterior. Nesse caso, eles agrupariam seus ETH sob algum SSP, que então socializaria suas recompensas e perdas, induzindo a mesma taxa de retirada para ambos os depositantes. É então bem formado falar de um único noETH, já que o valor do claim é compartilhado por ambos os depositantes, proporcional à quantidade que depositaram.

Liquefação

Nossos depositantes agora possuem um ativo virtual que chamamos de noETH. Este ativo virtual é um direito que representa a participação no montante atual apostado pelo SSP sob o protocolo Ethereum. Embora isso já pareça uma versão líquida da posição do ETH em jogo, gostaríamos de enfatizar que um passo adicional é necessário para chegar lá: a liquefação por meio da emissão de um token que representa o direito aos ativos noETH. A posição noETH é tornada líquida, ou seja, fungível e transferível. Escrevemos esta operação com o operando L., para que o ativo L.noETH seja uma abstração, por exemplo, de stETH ou cbETH, ou de qualquer outro ativo conhecido como um Token de Staking Líquido 'LST'.

Para tornar isso evidente, desagregamos as funções do SSP como protocolo de coleta de participação dos delegados e os operadores de nó fornecendo os serviços de validação para o SSP. Em seguida, obtemos os seguintes balanços:

Quando o SSP é simplesmente um invólucro entre alguns operadores de nó e o delegador, o passo de obter L.noETH de noETH é quase invisível dada a natureza das blockchains, onde o "ativo contábil" noETH, escrito como uma entrada de livro razão, acaba por ser o próprio ativo líquido L.noETH, programável e pronto para ser composto. Em outras palavras, se já temos um token representando algum noETH como uma entrada de blockchain, noETH e L.noETH são indistinguíveis. Desejamos enfatizar a diferença de qualquer maneira, uma vez que existem casos em que os delegadores não têm acesso a uma representação líquida (do ponto de vista da blockchain) de seu ativo em jogo. Por exemplo, no passado, depositantes que apostaram seu ETH com a Coinbase não receberam da Coinbase o ativo líquido cbETH. Nesse caso, os depositantes tinham direito a uma reivindicação virtual representando alguma linha nas entradas de livro interno do banco de dados da Coinbase, que não foram escritas em uma blockchain.

Funções da SSP

Em muitos casos, o SSP, visto como protocolo, não é apenas um invólucro simples, um contrato on-chain que recebe ETH e imprime L.noETH em troca. A função principal do SSP é intermediar a relação entre um principal (o delegante) e agentes (operadores de nó). Se o principal não confia que os agentes lhe fornecerão um rendimento adequado enquanto protegem os ativos do principal, o principal não delegará seus ativos aos operadores de nó para apostar em seu nome. Como os SSPs garantem boas garantias?

1. O primeiro componente é incentivar o bom desempenho dos operadores de nó. Os operadores de nó recebem mais recompensas do protocolo Ethereum quanto melhor desempenham seus serviços de validação. Os incentivos são facilmente alinhados ao permitir que os operadores de nó compartilhem nos lucros que eles criam para seus delegados, via taxas.
2. O segundo componente é desencorajar partes maliciosas de se tornarem operadores de nó. Poderíamos assumir que, no pior caso, essas partes maliciosas são intrinsecamente motivadas a atacar o protocolo Ethereum e causar um grande evento de redução de custos mínimo para si mesmas. Duas abordagens existem aqui. Poderíamos exigir que os operadores apostem algo, de modo que esses ataques sejam o mais custosos possível para os operadores. Também poderíamos restringir os operadores de nó, impedindo-os de realizar unilateralmente ações puníveis.

Pools como Lido lidam com o segundo problema ao curar um conjunto de operadores de nós, de modo que o desempenho seja garantido pelo protocolo e DAO da Lido. Seus operadores não têm ETH em jogo, mas @mikeneuder/magnitude-and-direction">sistemas externos de execução (de soft como “reputação em jogo” para hard como saques acionados pela camada de execução, conforme discutido no segundo post) destinam-se a garantir seu bom comportamento.

Algo em jogo para desencorajar operadores maliciosos

Enquanto isso, construções como o Rocket Pool incentivam a validação honesta por parte dos operadores de nós que não são verificados nem empregados por alguma organização, contribuindo sem permissão. O operador de nó abre um Minipool, primeiro contribuindo com sua própria participação, seja 8 ou 16 ETH. O protocolo então complementa a participação do operador do nó com a participação recebida dos delegantes. Como corolário, o rendimento do operador do Minipool em sua própria participação aumenta com seu desempenho.

Note que o operador também deve fornecer alguma quantidade de RPL, o token da Rocket Pool, proporcional à quantidade de participação que precisou pegar emprestado do pool de ETH delegado para complementar seu próprio Minipool. Não mostramos isso nos balanços a seguir e destacamos alguns ativos do mesmo tipo com cores diferentes para ilustrar sua proveniência (ETH verde pertence ao delegador, ETH roxo pertence ao operador).

Quanto menor for o colateral postado pelo operador, maior se torna o risco de ataque alavancado, onde o operador precisa de uma pequena quantidade de fundos para controlar uma quantidade muito maior de participação na rede Ethereum Proof-of-Stake (PoS). Para a Lido, o risco de ataque alavancado é infinito considerando apenas os ativos on-chain colocados em jogo pelos operadores, mas obviamente menos do que infinito considerando sua reputação, contratos e fluxos de caixa futuros esperados a partir de validação honesta. Para os operadores da Rocket Pool, por exemplo, aqueles que abrem Minipools colateralizados com 8 ETH, o fator de alavancagem é de 4x, já que 8 ETH permite que eles controlem 32 ETH de participação no protocolo Ethereum PoS. Podemos exigir um colateral mais baixo dos operadores?

Operadores de nós restritivos

Uma maneira de reduzir ainda mais os riscos de validação maliciosa é comprometer credívelmente os operadores de nó a ações específicas, por exemplo, comprometê-los a nunca produzir mensagens puníveis. Mais fácil dizer do que fazer!

Aqui, tecnologias de validação distribuída (DVT) podem ajudar, garantindo que todas as mensagens do operador sejam verificadas e aprovadas por um quórum de nós antes de serem lançadas na rede com uma assinatura válida. Diva, um protocolo de staking, integra DVT para limitar as ações de um operador. O operador deve apostar algum divETH (LST da Diva), ou seja, uma quantia equivalente a 1 ETH para obter uma chave compartilhada. Um conjunto de 16 chaves compartilhadas forma um quórum de nós DVT, bem como um único validador virtual, conforme mostrado abaixo. Omitimos o protocolo Ethereum, que simplesmente emite a reivindicação soETH na última etapa e recebe ETH coletado de delegadores e operadores (ETH verde pertence ao delegador, enquanto ETH roxo e amarelo são fornecidos pelos operadores). Também mostramos apenas dois operadores em vez de 16.

O cálculo do fator de alavancagem para Diva não é tão simples. Contribuir com 1 ETH-equivalente ao validador virtual não "ganha" o controle de qualquer quantidade de ETH atualmente em jogo, uma vez que as ações conjuntas de mais de 2/3 do quórum decidem as mensagens do validador virtual. Note, no entanto, que o protocolo permite que o proprietário de um único ETH se torne um operador e receba uma reivindicação noETH, resgatando o rendimento obtido da validação do Ethereum PoS.

Além do fator de alavancagem, outra métrica relevante aqui é a proporção entre a quantidade de LSTs em circulação e a quantidade de stake do operador ou fator de garantia. Uma proporção alta implica que uma menor quantidade de stake do operador está sendo colateralizada para validar em nome de uma maior quantidade de stake do delegante. No caso da Rocket Pool, Minipools de 8 ETH têm um fator de garantia igual a 3x, já que 8 ETH colateralizam 24 rETH no total. Enquanto isso, o fator de garantia de um validador virtual Diva é de 1x, pois 16 partes-chave (16 ETH) colateralizam 16 divETH. Um fator de garantia alto “faz espaço” para mais stake ser delegado. Diva deve então recrutar mais stake do operador por unidade de stake delegado para oferecer seus serviços. Por outro lado, permitir que operadores que colateralizam um único ETH amplia o conjunto de operadores elegíveis para aqueles com menor capital.

Validação solo na Liquid

Acima, aprendemos que os detentores de um LST exigem que os operadores que validam em seu nome façam um bom trabalho. Essa garantia é fornecida por meio de contratação externa no caso de protocolos do tipo Lido, ou pelo fato de o operador colocar seu próprio capital em jogo junto com o capital de seus delegados. Este último requer um modelo sólido de teoria dos jogos para garantir que o capital em jogo pelo operador não seja tão baixo a ponto de permitir ataques baratos e, em última análise, destruir o valor do LST para seus detentores.

Agora fazemos uma pergunta distinta. O delegador obtém L.noETH da participação em pool e intermediando as reivindicações por meio de um protocolo que emite uma representação líquida do valor delegado, módulo recompensas, penalidades e taxas. Um delegador pode obter L.soETH? Em outras palavras, um único staker solitário poderia emitir uma posição líquida a partir de sua posição de validação?

O problema aqui é que os detentores do ativo L.soETH devem ter confiança de que o valor de seu direito não será destruído por uma ação maliciosa do staker solo, por exemplo, ser punido. Já vimos uma abordagem, via DVTs, para restringir as ações do operador durante a validação.

Uma abordagem diferente para DVT consiste em vincular as ações do staker solo, de modo que seu próprio risco de corte seja reduzido pela construção de hardware. “Validação solo na Liquid” de Justin Drake utiliza SGX para garantir que a chave de assinatura do validador nunca assine uma mensagem passível de penalização. SGX permite que o software pré-comprometido seja executado sem adulteração, embora existam as advertências habituais em relação à sua segurança, que estão fora do escopo deste artigo. O staker solo fornece todo o capital (32 ETH), mas é capaz de criar um LST representando sua própria validação e “liberando” seu capital do protocolo Ethereum, para ser usado novamente, por exemplo, como garantia para outras aplicações.

Detalhes linha por linha:

1. O dispositivo SGX gera uma chave privada, uma chave pública e uma atestação que comprova o compromisso com um trecho de código que impede o staker solo de realizar ações passíveis de penalização com sua chave de assinatura privada.
2. As chaves de atestação e públicas são fornecidas ao staker solo.
3. O staker solo registra estes com o contrato LST implantado on-chain, que é responsável por cunhar o ativo líquido validador solo. O staker solo também fornece ao contrato ETH, sua participação.
4. O ETH é encaminhado do contrato LST para o contrato de depósito, e um ativo de staking soETH é devolvido ao contrato LST, que agora filtra a saída do validador do protocolo PoS. O contrato LST cunha o ativo L.soETH, que é uma representação líquida do ETH em jogo do staker.

O ativo L.soETH é fungível com aqueles cunhados por outros stakers solo usando o mesmo procedimento. Por construção, o staker solo líquido só é capaz de cunhar 31 L.soETH dos seus 32 ETH em jogo. O extra de 1 ETH é usado como garantia para pagar as partes que liquidam a posição sem permissão, quando o saldo do staker solo fica abaixo de 32 ETH, e contabilizar a garantia congelada enquanto o validador está na fila depois de uma saída. Isso garante que 1 L.soETH sempre seja garantido por 1 ETH.

Quais são os usos do ativo L.soETH?

1. O staker solo que emite L.soETH poderia usar este ativo L.soETH como garantia para outros serviços. Esses serviços poderiam considerar que esta é uma “boa garantia”, uma vez que a única maneira para o staker solo de degradar sua qualidade é ficar offline e incorrer em penalidades (não slashing). Por construção, o staker solo é, no entanto, encerrado assim que seu saldo de soETH se desvia mesmo em centésimo de um ETH do saldo inicial de 32 ETH.
2. O staker solo também poderia vender o ativo L.soETH para outros detentores, recebendo os lucros. O ativo L.soETH precisaria ser um ativo produtivo em si mesmo, conforme descrito por Justin no “sETH produtivo vs não produtivona seção de seu post, onde o ativo L.soETH se torna uma reivindicação não apenas ao principal em jogo, mas também às recompensas obtidas no jogo, por exemplo, recompensas de consenso e MEV (há dificuldades para internalizar o MEV de forma minimizada em confiança).
   1. Observe que a venda do ativo L.soETH não dá ao staker solo uma alavancagem extra para lançar um ataque ao Ethereum. A alavancagem é obtida ao colocar uma pequena quantidade de fundos em jogo e controlar uma quantia maior no protocolo PoS. No entanto, o dispositivo SGX impede que o staker realize ações passíveis de penalização.

Conclusão da liquefação

A tabela a seguir resume os 4 estudos de caso discutidos acima:

A liquefação é uma forma para um staker extrair “mais suco” de sua garantia em jogo. No post seguinte, discutiremos o re-staking como uma alternativa relacionada para criar mais ativos a partir da própria participação.

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [espelho], Todos os direitos autorais pertencem ao autor original [O preço da agência]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.