Muito obrigado a Anders Elowsson pelas discussões iniciais que motivaram esta série de posts 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 em Unsplash.

Estaca, reestaca, estaca líquida, reestaca líquida, tokens de estaca líquida reestacados, operadores de nós 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 estaca do protocolo.

Nas discussões dentro da nossa equipa, sentimos a necessidade de uma linguagem precisa que nos permitisse eliminar ambiguidades em relação à arquitetura destes mecanismos. Esperamos enfatizar a existência de pontos de controlo e desalinhamentos de incentivos através do uso de notação e balanços, uma vez que as nuances são muito importantes para destacar adequadamente as oportunidades e os riscos. O exercício foi feito principalmente para a nossa própria compreensão, mas ao passar por ele, sentimos que proporcionava uma forma útil de agregar uma coleção de factos e discussões díspares numa abordagem coerente e sistemática.

Nesta postagem e nas duas seguintes, apresentamos essas construções juntamente com estudos de caso. Não pretendemos fazer uma revisão exaustiva de todo o material produzido por todas as equipes brilhantes que trabalham nesses mecanismos, 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-estaca
3. Parte 3: Conjuntos de construção avançados para maiores de 16 anos

A série atual de posts também não tira conclusões sobre a optimalidade ou o uso destas construções, para além de fornecer definições e contexto para a sua existência. Os posts futuros irão abordar estas questões e oferecer propriedades destes mecanismos, tais como a sua utilidade para várias classes de stakers e a sua economia num contexto mais amplo.

Vamos a isso!

Ativo

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

Balanços

A seguir, ilustramos as nossas construções com balanços que mostram a criação e transferência de ativos entre várias partes envolvidas. Sempre fornecemos os balanços na mesma formatação:

1. A primeira linha representa o “pré-estado”, denotando quais ativos são atualmente possuídos por cada parte.
2. A última linha representa o “estado posterior”, 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, com uma nova linha simplesmente denotando um novo conjunto de operações, dividido dos outros com o propósito de exposição.

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. Mintagem 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 é então uma responsabilidade para a Parte B e um ativo para a Parte A. No exemplo a seguir, a Parte A transfere Ativo para a Parte B e recebe uma Reivindicação da Parte B.

Não utilizamos balanços de uma forma muito ortodoxa, sendo mais inspirados pelo Economia do Dinheiro e da Bancacurso, bem como de Daniel H. Neilson.Em breve separadosboletim informativo (afirmando, para que conste, que provavelmente não somos tão rigorosos como qualquer um deles). No entanto, acreditamos que este conjunto mínimo de operações é suficiente para fornecer a intuição necessária.

Protocolo de estaca

Estaca solitária

A primeira operação básica consiste em colocar ETH em estaca no protocolo Ethereum de Prova de Estaca. 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 folhas de balanço, que são lidas linha por linha entre as várias partes:

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

Note que não representamos recompensas da "camada de execução", por exemplo, taxas de prioridade e MEV. Estas 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 estacador solo que assume os deveres de produtor de blocos.

Usando um Fornecedor de Serviços de Estaca (SSP)

Uma relação mais complexa está em jogo quando um Prestador de Serviços de Estaca (PSE) intermedia a relação entre o detentor que deseja estacar ("delegante") e o protocolo Ethereum. Neste caso, o detentor de ETH primeiro fornece ao PSE ETH nativo com o propósito de que ele deve ser estacado. O PSE estaca o ETH e é concedido controle sobre o ativo "soETH" em execução na camada de validação. Ele confere um ativo virtual noETH ao delegante (o "no" significa operador de nó), contra o qual seu ETH em jogo é resgatável.

O nosso uso da palavra "resgatável" já introduz alguma incerteza aqui. Como vimos acima, o protocolo Ethereum permite que o staker a solo retire o seu saldo soETH contra ETH em paridade. Será que isto também se aplica ao staker que delega o seu ETH ao SSP em troca de noETH? Em geral, isso não é verdade. Em primeiro lugar, 1 noETH poderia resgatar menos do que 1 soETH, se ocorresse um corte. Em segundo lugar, uma vez que a maioria dos SSPs fornece o 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. Um balanço mais preciso separaria o principal do rendimento, por exemplo:

Aqui, “desagregamos” o ativo soETH entre o principal pETH e o rendimento yETH. O pETH resgata no máximo 32 ETH, a menos que ocorra um corte. 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 pode sempre receber seu principal na íntegra, incluindo cortes, de modo que exista uma taxa de câmbio de 1:1 entre no.pETH e pETH. No entanto, o SSP cobra uma taxa, de modo que a taxa de câmbio entre no.yETH e yETH seja inferior a 1 (1 no.yETH resgata menos que 1 yETH). A desagregação do ativo pode ser útil em alguns lugares, mas também introduz complexidade adicional que não é fundamental para as seções seguintes, então continuamos a usar soETH e noETH para representar a reivindicação como um todo.

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

1. Sem agrupamento: Um SSP abre múltiplos pools paralelos, um para cada depositante. Suponha que os depositantes A e B fornecem seu ETH ao SSP, que abre os validadores A e B, um para cada depositante. Suponha então que o validador A é penalizado em metade do 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 de 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 para serem colocadas em estaca, o que significa que se os depositantes A e B estivessem interessados em apostar apenas 16 ETH cada um, não poderiam fazê-lo com a construção detalhada no ponto anterior. Neste 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, uma vez que o valor da reivindicação é compartilhado por ambos os depositantes, proporcional à quantia depositada.

Liquefação

Os nossos depositantes detêm agora um ativo virtual que chamamos de noETH. Este ativo virtual é uma reivindicação que representa a participação do montante atual apostado pelo SSP ao abrigo do protocolo Ethereum. Embora isto já pareça uma versão líquida da posição ETH em jogo, queremos salientar que um passo adicional é necessário para lá chegar: a liquefação através da emissão de um token que representa a reivindicação dos ativos noETH. A posição noETH é tornada líquida, ou seja, fungível e transferível. Escrevemos esta operação com o operando L., de forma que o ativo L.noETH seja uma abstração por exemplo, de stETH ou cbETH, ou qualquer outro ativo conhecido como um Token de Estaca Líquida "LST".

Para tornar isso evidente, desagregamos as funções do SSP como a coleta de estacas do protocolo pelos delegados e os operadores de nós que fornecem os serviços de validação para o SSP. Obtemos então os seguintes balanços:

Quando o SSP é simplesmente um invólucro entre alguns operadores de nós e o delegante, 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 que representa algum noETH como uma entrada de blockchain, noETH e L.noETH são indistinguíveis. No entanto, desejamos salientar a diferença, uma vez que existem casos em que os delegantes 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. Neste caso, os depositantes tinham direito a uma reivindicação virtual representando alguma linha nas entradas de livro-razão internas da base de dados da Coinbase, que não estavam escritas em uma blockchain.

Funções do 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ós). Se o principal não confia que os agentes lhes proporcionarão um rendimento adequado enquanto protegem os ativos do principal, o principal não delegará seus ativos aos operadores de nós para apostar em seu nome. Como é que os SSPs fornecem boas garantias?

1. O primeiro componente é incentivar um bom desempenho para os operadores de nó. Os operadores de nó recebem mais recompensas do protocolo Ethereum quanto melhor executam os seus serviços de validação. Os incentivos são facilmente alinhados ao permitir que os operadores de nó partilhem nos lucros que criam para os seus delegados, através de taxas.
2. O segundo componente é desencorajar as partes maliciosas de se tornarem operadores de nós. Podemos assumir que, no pior cenário, essas partes maliciosas estão intrinsecamente motivadas a atacar o protocolo Ethereum e causar um grande evento de corte de custos mínimos para si mesmas. Existem duas abordagens aqui. Poderíamos exigir que os operadores colocassem algo em jogo, de forma a tornar esses ataques o mais caros possível para os operadores. Também poderíamos restringir os operadores de nós, impedindo-os de realizar ações passíveis de corte de forma unilateral.

Pools como Lido lidam com o segundo problema ao selecionar um conjunto de operadores de nós, de forma a garantir o desempenho pelo protocolo e DAO da Lido. Seus operadores não têm ETH em jogo, mas @mikeneudersistemas externos de execução (desde os mais suaves, como a “reputação em jogo”, até aos mais duros, como retiradas acionadas pela camada de execução, conforme discutido no segundo post) são destinados a garantir o seu bom comportamento.

Algo em jogo para desencorajar operadores maliciosos

Entretanto, construções como Rocket Pool incentivam a validação honesta por parte de 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 estaca, seja 8 ou 16 ETH. O protocolo então complementa a estaca do operador de nó com a estaca recebida dos delegadores. Como corolário, o rendimento do operador do Minipool em sua própria estaca aumenta com seu desempenho.

Observe que o operador também deve garantir alguma quantidade de RPL, o token do Rocket Pool, proporcional à quantidade de participação que eles tiveram que pegar emprestado do pool de ETH delegado para completar seu próprio Minipool. Não o mostramos nos balanços seguintes, e destacamos alguns ativos do mesmo tipo com cores diferentes, para ilustrar a sua proveniência (o ETH verde pertence ao delegante, o ETH roxo pertence ao operador).

Quanto menor for o colateral postado pelo operador, maior se torna o risco de ataque alavancado, onde o operador requer 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 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 da validação honesta. Para os operadores do Rocket Pool, por exemplo, aqueles que abrem Minipools colateralizados por 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?

Restringir operadores de nós

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

Aqui, as 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. A Diva, um protocolo de estaca, integra o DVT para limitar as ações de um operador. O operador deve apostar algum divETH (LST da Diva), ou seja, um valor equivalente a 1 ETH para obter uma chave. Um conjunto de 16 chaves forma um quórum de nós DVT, bem como um único validador virtual, conforme ilustrado 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 a Diva não é tão direto. Contribuir com 1 ETH-equivalente para o validador virtual não lhe dá controle sobre qualquer quantidade de ETH atualmente em jogo, uma vez que as ações conjuntas de mais de 2/3 da quórum decidem as mensagens do validador virtual. No entanto, note 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 a partir da validação PoS do Ethereum.

Além do fator de alavancagem, outro indicador relevante aqui é a relação entre a quantidade de LSTs em circulação e a quantidade de estaca do operador, ou fator de garantia. Uma alta relação implica que uma menor quantidade de estaca do operador está colateralizada para validar em nome de uma maior quantidade de estaca delegada. Para o Rocket Pool, os 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, uma vez que 16 ações-chave (16 ETH) colateralizam 16 divETH. Um alto fator de garantia 'abre espaço' para mais estacas serem delegadas. A Diva deve então recrutar mais estaca de operador por unidade de estaca delegada para oferecer seus serviços. Por outro lado, permitir operadores que colateralizem um único ETH expande o conjunto de operadores elegíveis para aqueles com menor capital.

Validação a solo na Liquid

Acima, aprendemos que os detentores de um LST requerem que os operadores que validam em seu nome façam um bom trabalho. Esta garantia é fornecida por contrato externo no caso dos protocolos do tipo Lido, ou pelo operador colocar seu próprio capital em jogo juntamente com o capital de seus delegados. Este último requer um modelo de jogo teórico sólido 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 delegante obtém L.noETH da estaca de pooling e media as reivindicações através de um protocolo que emite uma representação líquida do montante delegado, módulo de recompensas, penalidades e taxas. Pode um delegante obter L.soETH? Em outras palavras, poderia um único validador emitir uma posição líquida a partir da sua posição de validação?

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

Uma abordagem diferente para DVT consiste em ligar as ações do staker solo de forma a reduzir o seu próprio risco de penalização por construção de hardware.Validação solo da Liquid” by Justin Drake emprega o SGX para garantir que a chave de assinatura do validador nunca assine uma mensagem passível de punição. O SGX permite que o software predefinido seja executado sem interferências, embora existam os habituais avisos em relação à sua segurança, que estão fora do âmbito deste artigo. O apostador individual fornece todo o capital (32 ETH), mas consegue criar um LST representando a sua própria validação e “libertando” o seu capital do protocolo Ethereum, para ser utilizado novamente, por exemplo, como garantia para outras aplicações.

Detalhes linha a linha:

1. O dispositivo SGX gera uma chave privada, uma chave pública e uma atestação que prova o compromisso com um pedaço de código que impede o estacador individual de realizar ações passíveis de punição com sua chave de assinatura privada.
2. As chaves de atestação e públicas são fornecidas ao estacador a solo.
3. O staker solo registra esses com o contrato LST implantado on-chain, que é responsável por cunhar o ativo líquido de validação solo. O staker solo também fornece ao contrato ETH, sua estaca.
4. O ETH é encaminhado do contrato LST para o contrato de depósito, e um ativo de estaca 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 os emitidos por outros detentores solos usando o mesmo procedimento. Por construção, o detentor solitário líquido só pode emitir 31 L.soETH dos seus 32 ETH em jogo. O extra 1 ETH é usado como garantia para reembolsar as partes que liquidam a posição sem permissão quando o saldo do detentor solitário fica abaixo de 32 ETH e contabilizar a garantia congelada enquanto o validador aguarda na fila após uma saída. Isso garante que 1 L.soETH seja sempre lastreado por 1 ETH.

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

1. O staker a solo que emite L.soETH pode utilizar este ativo L.soETH como garantia para outros serviços. Estes serviços podem considerar que esta é uma “boa garantia”, uma vez que a única forma de o staker a solo degradar a sua qualidade é ficar offline e incorrer em penalizações (não cortes). No entanto, por construção, o staker a solo sai assim que o seu saldo de soETH se desviar mesmo que por centésimos 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 rendimentos. O ativo L.soETH precisaria ser um ativo produtivo em si, 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 na aposta, por exemplo, recompensas de consenso e MEV (existem dificuldades para internalizar o MEV de forma minimizada em confiança).
   1. Note que vender o 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 quantia de fundos em jogo e controlar uma quantia maior no protocolo PoS. No entanto, o dispositivo SGX impede o staker de realizar ações passíveis de penalização.

Conclusão da liquefação

A tabela seguinte resume os 4 estudos de caso discutidos acima:

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

Aviso legal：

1. Este artigo é reproduzido a partir de [Gateespelho], Todos os direitos de autor pertencem ao autor original [O preço da agência]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer 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.