diff --git a/docs/arch/_catagory_.json b/docs/arch/_catagory_.json deleted file mode 100644 index e9ed86b..0000000 --- a/docs/arch/_catagory_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Puffer Protocol", - "position": 4 -} \ No newline at end of file diff --git a/docs/arch/img/arch.png b/docs/arch/img/arch.png deleted file mode 100644 index 749d109..0000000 Binary files a/docs/arch/img/arch.png and /dev/null differ diff --git a/docs/arch/overview.md b/docs/arch/overview.md deleted file mode 100644 index d3e664e..0000000 --- a/docs/arch/overview.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -sidebar_position: 1 -title: Overview ---- - - -> Puffer's goal is to make validating more accessible and profitable for at-home nodes, thereby contributing to Ethereum's security and censorship resistance. :blowfish: - -Restaking is a paradigm shift that will forever change web3's infrastructure and unlock unprecedented value for Ethereum validators and the [AVSs](#puffer-protocol-rules) they operate. However, as with earlier developments like MEV and liquid staking, there is potential to centralize Ethereum. Now that Pandora's Box is opened, building protocols that preserve decentralization is essential. In pursuit of this goal, Puffer has built the first native liquid staking protocol on [Eigenlayer](https://www.eigenlayer.xyz/) with Ethereum's ethos in mind. To counteract the risk of centralization, Puffer is preemptively [self-capping its pool size](#burst-threshold) and implementing guardrails to mitigate the negative externalities that restaking may have on the Ethereum ecosystem. - -At its core, the Puffer Protocol is a liquid staking protocol where node operators are permissionlessly allocated ETH to launch an Ethereum PoS validator. Puffer nodes can restake to operate AVSs on top of Eigenlayer. Puffers are users who stake ETH for the pufETH LST, which is expected to increase in value over time as the Puffer Protocol accrues validator and restaking rewards. PUFI token is used to govern the protocol via voting in the Puffer DAO. Some important duties include approving which AVSs Puffer nodes can use and which ones to allocate protocol treasury ETH to in the form of Economic Security as a Service (ESaaS). - -### Guiding Principles -The Puffer Protocol functions as a platform to increase the profitability of at-home nodes operating as Ethereum validators and web3 infrastructure providers, helping to cement a pocket of decentralization within the wider validator set. This is achieved through three core guiding principles: - -1. *increase capital efficiency*: -> By reducing the amount of ETH required to operate a node, Puffer allows for far greater node participation and diversity than the status quo. However, [care must be taken](../background/slash.md#liquid-staking-protocol-considerations) to protect both nodes and stakers. Puffer's [Secure-Signer](../tech/securesigner.md) and [Guardians](#guardians) allow the bond requirement to be reduced to just 2 ETH by mitigating the risk of slashing and inactivity penalties. In the future, Puffer's [Fractal DVT](#dvt-in-puffer) massively decreases the barrier as hundreds of nodes can split the bond requirement. - -2. *increase economic opportunities*: -> To truly incentivize people to run nodes from home, increasing node operator profit margins is essential. Decentralized liquid staking protocols that fail to do so will need help attracting nodes, as they are economically better off staking their ETH on centralized platforms at the expense of Ethereum's security. In the Puffer Protocol, nodes can increase their profit margins by restaking to operate unique web3 infrastructure and services. - -3. *increase hardware efficiency*: -> Validators must pay an upfront hardware cost and ongoing electricity and internet costs that hurt their overall profitability. Additionally, validator hardware must be better utilized as the main duty of signing attestation messages is only required once per epoch (every 6.4 minutes). Restaking increases the hardware efficiency as the latent compute power can generate additional revenue streams to get a better ROI on their hardware. TEE-compatible hardware comes at comparable costs to the hardware typically recommended for Ethereum validators. Puffer nodes using TEEs benefit from slash protection to reduce risk and unlock unique restaking services, maximizing their ROI on the fixed hardware costs. - - - -### Puffer Protocol Rules -Since the Puffer Protocol is built on top of Eigenlayer, its rules can be defined as an [actively validated service](https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/AVS-Guide.md) or AVS. Eigenlayer defines AVSs as services or middlewares that a restaker can opt in to, where provably incorrect behavior can be programmably slashed. For example, a validator's 32 ETH deposit can be programmably slashed if fraud is proven while restaking to operate an optimistic rollup. If the Puffer Protocol's AVS is violated, the offending validator's ETH will be programmably slashed, and the amount distributed back to the pool. - -1. To actively protect Puffers' ETH from [inactivity penalties](../background/slash.md#inactivity-risk), each validator's [current balance](https://kb.beaconcha.in/glossary#current-balance-and-effective-balance) is required to remain above a threshold set by the Puffer DAO. This threshold should be low enough to allow reasonable downtime but high enough to incentivize good performance. -2. MEV-Smoothing is vital to curb centralization within the protocol. It allows at-home nodes to earn more than they would on their own and reduces the economies of scale of centralized staking operations. Validators proposing blocks are required to distribute the execution rewards with the pool. If theft is proven on-chain, the offending validator is penalized. - -### Puffers -Puffers are the individuals who stake their ETH at the Puffer Protocol to receive the pufETH liquid staking token. When the Puffer stakes `≥ 0.01` ETH it is added to a pool of ETH. Part of this pool is provisioned to nodes to meet the 32 ETH requirement to activate an Ethereum validator, and the rest provides exit liquidity for when Puffers want to redeem ETH for their pufETH. - -### Nodes -The ETH staked by Puffers buoy the Puffer Protocol, so protecting them is one of the protocol's main priorities. The protocol requires all nodes to be economically bonded for proper incentivization, and should penalties accrue, they are first deducted from this bond. To minimize penalties, enclaves reduce slashing risk, while Guardian support is in place to counteract node inactivity. - -To accommodate different risk preferences and ETH requirements, nodes can choose from three modes of operation, ranging from high to low capital efficiency, with corresponding requirements. Secure-Signer nodes enjoy increased capital efficiency and access to [enclave](../tech/securesigner.md#what-is-it)-specific AVSs. Guardian support is currently needed for bonds less than 16 ETH to prevent inactivity penalties from threatening staker eth until [EIP-7002](https://github.com/ethereum/EIPs/pull/7002) removes this requirement. Before this, nodes with a 16 ETH bond could join without Guardian support. - -Capital Efficiency | Bond (ETH) | Guardian Support | TEE Required ---- | --- | --- | --- -High | 2 ETH | Yes | Yes -Mid | 4 ETH | Yes | No -Low | 16 ETH | No | No - -### Rewards -pufETH is a reward-bearing token akin to [Compound's cToken](https://docs.compound.finance/v2/ctokens/#ctokens), which is optimal regarding DeFi compatibility. As the protocol generates rewards, the amount of ETH backing pufETH increases, increasing the conversion rate between the two. Holding liquid pufETH allows one to earn staking and restaking rewards over time while still being able to participate in DeFi. - -**Puffer Rewards** -> Puffers deposit ETH at the PufferPool contract to mint pufETH. At the protocol's inception, the conversion rate would be one-to-one, but assuming the protocol performs well, i.e., accrues more rewards than penalties, the conversion rate would value pufETH higher than ETH. Thus Puffers holding pufETH can expect its value to increase over time. - -**Node Rewards** -> Upon registering validator keys, Puffer nodes mint their bond's worth of pufETH, which is locked until they exit the protocol. As the node generates consensus, execution, and restaking rewards, they are rewarded liquid ETH dependent on commission rates set by the Puffer DAO, with the remainder sent to the PufferPool and treasury. Since nodes hold locked pufETH, they also share in the rewards generated by other nodes in the protocol. This allows for efficient MEV-Smoothing and helps to align node incentives. - -### Guardians -The Guardians are a permissioned set of nodes whose job is to ensure the smooth functioning of the protocol. They have two responsibilities that will eventually be phased out as [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) and [EIP-7002](https://github.com/ethereum/EIPs/pull/7002) are implemented in upcoming hardforks: -1. *reporting the amount of ETH that backs pufETH* -> To calculate the conversion ratio between ETH and pufETH, the main contract must be aware of the amount of ETH currently backing the protocol. This requires summing the on-chain balances of all active validators with their current balances on the beacon chain. The Guardians are currently responsible for performing this computation, but after EIP-4788, this will be replaced by a trustless ZKP. - -2. *exiting nodes who breached the Puffer Protocol AVS* -> The first rule in the [Puffer Protocol AVS](#puffer-protocol-rules) is in place to protect offline nodes from harming Puffers. Unfortunately, until EIP-7002 is implemented, exiting validators cannot be done on-chain but instead requires signing exit messages with the validator's key. Since EIP-7002 may take years to implement, to be practical and proactive about preserving decentralization before it is too late, the Puffer Protocol requires its nodes with a `< 16` ETH bond to encrypt their validator keyshares to the Guardians' enclaves. These enclaves are implemented such that they can only sign an exit message with the validator keyshare. As soon as EIP-7002 is implemented, the Guardian 'training wheels' will be removed. - -To reduce counterparty risk, the Guardians have many guardrails in place. They are composed of public community members with a strong alignment with Ethereum's ethos and reputation at stake. The Guardians must use enclaves to increase the security of their actions and require quorum from a high threshold of Guardians (e.g., 8/9 signatures). - -### Withdrawals -**Puffer Withdrawals** -> Puffers can burn their pufETH to redeem their original ETH plus the accrued rewards when there is sufficient liquidity in the protocol's withdrawal pool. A portion of all Puffer deposits, rewards, and node withdrawals are added to the withdrawal pool to provide exit liquidity. - -**Node Withdrawals** -> Nodes can fully withdraw from the Puffer Protocol by proving they have exited from the beacon chain. Upon fully exiting the Puffer Protocol, their locked pufETH is burned and redeemed for liquid ETH equal to their `original bond + accrued rewards - penalties`. For example, if a node with a 2 ETH bond exits with a validator balance of 32 ETH and the ratio of pufETH:ETH has doubled since they registered, they would receive 4 ETH, and 28 ETH is returned to the pool. - -### Governance -One of Puffer's goals is to build an unstoppable decentralized protocol that can eventually continue to grow and operate without relying on Puffer's core team. For this reason, we strive to minimize the role of governance in the protocol. -The PUFI token will primarily be used for the following: -- pausing and upgrading contracts in the event of vulnerabilities and Ethereum hard forks -- voting on protocol parameters like commission rates -- managing the Puffer Protocol treasury in the form of grants and ESaaS -- whitelisting AVSs that are aligned with Ethereum's ethos - -### Restaking -Since Puffer is built on Eigenlayer, all Puffer nodes can become native restakers to increase their rewards. Such restaking jobs span from important middlewares such as bridges and oracles to services like data availability layers and L2 sequencers. Additionally, the nodes with enclave support can participate in AVSs unique to Puffer, like privacy-preserving L2s and [ZK-2FA](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462). Puffer is committed to supporting only the AVSs that are not considered [problematic for Ethereum](https://vitalik.ca/general/2023/05/21/dont_overload.html). - -### DVT in Puffer -The Puffer Protocol has been designed to be compatible with DVT. When used with Secure-Signer, this combination provides the best slash-protection guarantees. Stay tuned for more information on Puffer's Fractal DVT, an extension of DVT that is only possible through enclaves. Fractal DVT allows DVT clusters to scale far beyond what is possible using standard DVT, allowing for greater decentralization and bond reductions. - -### Burst Threshold -As part of Puffer's commitment to Ethereum's decentralization, the size of the Puffer Pool will be self-capped. This is called the *Burst Threshold* with a maximum capacity of 22%. If the Puffer Pool reaches 22% of the validator set, pufETH minting and node onboarding will freeze. - -This commitment is critical to ensure that the Puffer Pool never breaches the [dangerous consensus threshold of 33%](https://twitter.com/dannyryan/status/1688644951230267392?s=46&t=bsdBaPIHlTHEWDDdVUJW4g), which threatens the stability of Ethereum. We firmly believe that the Burst Threshold must be included from day one rather than after the protocol is profitable. \ No newline at end of file diff --git a/docs/background/_catagory_.json b/docs/background/_catagory_.json deleted file mode 100644 index b9f338c..0000000 --- a/docs/background/_catagory_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Background", - "position": 2 - } - \ No newline at end of file diff --git a/docs/burst-threshold.md b/docs/burst-threshold.md new file mode 100644 index 0000000..c90e5b1 --- /dev/null +++ b/docs/burst-threshold.md @@ -0,0 +1,17 @@ +--- +title: Burst Threshold +slug: /protocol/burst-threshold +--- + +:::info +The Burst Threshold is Puffer's commitment to Ethereum's Ethos. +::: + + +### Burst Threshold + +Puffer is [committed to self-capping](https://twitter.com/puffer_finance/status/1697817894900711700?s=20) its validator marketshare to 22% of Ethereum’s validator set, which we refer to as the protocol's *Burst Threshold*. Instead of abruptly pausing staking and NoOp registration once the burst threshold is reached, Puffer introduces a mechanism to organically reduce staker demand as the protocol reaches the threshold. + +As the protocol reaches 22%, the number of mintable validator tickets will be reduced such that it can only sustain existing validators but not new ones. + +This pledge is critical to ensure that the Puffer Pool never breaches the [dangerous consensus threshold of 33%](https://twitter.com/dannyryan/status/1688644951230267392?s=46&t=bsdBaPIHlTHEWDDdVUJW4g), which threatens the stability of Ethereum. We firmly believe that the burst threshold must be included from day one rather than after the protocol is profitable. \ No newline at end of file diff --git a/docs/faq.md b/docs/faq.md index 3e324df..82819ef 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -1,64 +1,73 @@ --- -sidebar_position: 6 title: FAQ +slug: /reference/faq --- +### 🐙 What is Puffer's Mission? + +> Puffer's mission is to define a new industry standard for secure validator operations, with the primary objective of preserving the decentralization of Ethereum. + +> Through our anti-slashing technology, we are reducing the risk of correlated slashing events across Ethereum while simultaneously promoting decentralization by lowering the barrier to entry for at-home validators and allowing for a more diverse node operator set. + +> However, reducing barriers to entry is one thing, but creating a more profitable platform for validators is crucial and is why Puffer has been pioneering in native restaking. + +> Ultimately, through Puffer's protocol, we hope to extend Ethereum's decentralization runway while its roadmap is being implemented. + ### 🐡 Explain ETH Liquid staking to me like I'm five? > Liquid staking is a simple and convenient way to gain exposure to ETH staking without having to meet the technical or financial requirements associated with vanilla staking, such as running your own node setup or having access to large amounts of capital (32 ETH). -> -> Instead, liquid staking providers (LSPs) take user deposits and stake them on behalf of their users using their own node operator set, taking on the heavy lifting for the user. -> -> In return, users receive tokens from the LSP that represents their deposit. These tokens can be redeemed on the open market anytime or used throughout DeFi as collateral. +> +> Instead, liquid staking protocols (LSPs) take user deposits and stake them on behalf of their users using their own node operator set, taking on the heavy lifting for the user. +> +> In return, users receive tokens from the LSP that represents their deposit. These tokens can be redeemed from the LSP for ETH, traded on the open market, or used throughout DeFi as collateral. +### ✌️ Explain restaking to me like I'm five? -### 🐙 What is Puffer's Mission? - -> Puffer's mission is to define a new industry standard for secure validator operations, with the primary objective of preserving the decentralization of Ethereum. -> Through our anti-slashing technology, we are reducing the risk of correlated slashing events across Ethereum while simultaneously promoting decentralization by lowering the barrier to entry for solo stakers and allowing for a more diverse node operator set. +> With 32 ETH you can stake to run a solo validator. Your ETH is used solely for the purpose of PoS. Restaking let's you use this ETH for running other jobs, allowing for more rewards but also more risk since you can get slashed from these new jobs. Puffer likes restaking because it allows validators to earn more with their existing hardware which isn't being fully taken advantage of through PoS alone. ### 🐟 What problems do LSPs currently face? > Although decentralized liquid staking sounds great in theory, the market will always favor centralized services in practice. This is because centralized staking providers can attract more liquidity by offering stakers higher yields than their decentralized competitors. -> -> This dilemma results from centralized services running a small and permissioned node operator set that allows them to scale much faster and operate more cost-effectively. For example, a node operator with 1024 ETH can operate 32x more validators than a node operator with 32 ETH when solo staking while paying the same costs. +> +> This dilemma results from centralized services running a small and permissioned node operator set that allows them to scale much faster and operate more cost-effectively. For example, a node operator with 1024 ETH can operate 32x more validators than a node operator with 32 ETH when solo staking while paying the same hardware costs. + +> In the context of liquid staking, centralized protocols with permissioned validators do not require their operators to put down collateral. Rather, they rely on reputation to ensure they behave honestly. In practice, some operators run tens of thousands of validators each. For a decentralized liquid staking protocol, running this many validators requires operators to have tens of thousands of ETH. +> +> Puffer's goal is to break this cycle by empowering decentralized validators with higher rewards while lowering thier barrier to entry. ### 🦈 How does Puffer help address some of these pain points? > Puffer is taking a unique approach to solving this problem by allowing node operators to earn additional revenue by utilizing their latent compute power. This allows node operators to amortize their infrastructure and operating costs without requiring additional capital to run parallel validators. -> -> This drastically lowers the barrier to entry for node operators, allowing decentralized LSPs to flourish and compete with centralized services that currently dominate the space. -> +> +> This drastically lowers the barrier to entry for node operators, allowing decentralized LSPs to flourish and compete with centralized services that currently dominate the space. +> > Over the coming months, we will be providing more information on our plans for generating additional yield for Puffer node operators. ### 🦑 How does Puffer protect validators from being slashed? > Secure-Signer is an open-source public good built by the Puffer team to increase decentralization across Ethereum while protecting validators from being slashed. -> +> > As an independent implementation of Consensys' Web3Signer remote-signing tool, Secure-Signer moves key management and signing logic out of the consensus client and into a secure enclave. -> +> > Validator keys are generated and stored within SGX's encrypted enclave memory. -> +> > If a compromised host or consensus client bug attempts to sign a slashable message, Secure-Signer's isolated SGX environment won't produce a signature, providing a strict security enhancement that prevents the validator from committing a slashable offense. -### 🧜‍♀️ How many ETH do I need to run a Puffer node? -> As preserving decentralization is our top priority, the minimum collateral requirement will start at 2 ETH for Puffer node operators. This lowers the barrier to entry for solo stakers, allowing for a robust and scalable permissionless node operator set. +### 🧜‍♀️ How much ETH do I need to run a Puffer node? + +> As preserving decentralization is our top priority, the minimum collateral requirement will start at 2 ETH for Puffer node operators. This lowers the barrier to entry for solo stakers, allowing for a robust and scalable permissionless node operator set. If the validator is using Puffer's anti-slasher, they can reduce this collateral requirement to 1 ETH. -### 🐢 When will Puffer launch? +### 🐢 When will Puffer launch? -> Puffer is in its early stages of development; however, our community can expect to see Puffer on testnet during the later stages of 2023, with a mainnet target for 2024. +> Puffer is coming soon™️! ### 🦞 Who runs Secure-Signer? -> Nodes run Secure-Signer alongside their consensus client. Nodes could be anyone with compatible hardware and multiples of 2 ETH. +> Nodes run Secure-Signer alongside their consensus client. Nodes could be anyone with compatible hardware and at least 1 ETH. ### 🦐 Can I get slashed if I go offline? -> No, inactivity is not considered a slashable offense. Refer to [Slashing on Ethereum PoS](background/slash.md). - -### 🦭 Is Puffer a non-custodial? - -> Puffer has different custody options as explained [here](../docs/arch/overview.md#nodes). Once EIP-7002 is implemented, every option will be fully non-custodial. +> No, inactivity is not considered a slashable offense. Refer to [Slashing on Ethereum PoS](slash.md). ### 🪼 How many validators have been slashed? Should we even care about slashable offenses? @@ -70,7 +79,7 @@ title: FAQ ### 🐳 How are validator keys being managed in your system? -> The node generates and stores all validator keys in the [Secure-Signer enclave](tech/securesigner#where-is-it-run). +> The node generates and stores all validator keys in the [Secure-Signer enclave](secure-signer.md#where-is-it-run). ### 🐠 Wasn't SGX hacked before? Why would you use it? @@ -78,11 +87,10 @@ title: FAQ > It is essential that Puffer relies on SGX as a **strict security enhancement**. Honest nodes are completely protected against all slashable offenses. However, should a nefarious node manage to break SGX, all that they would learn is knowledge of their validator private key. Knowledge of one's validator private key is the status quo for _all_ existing staking operations and does not provide the node with any way to steal from the pool. -### 🐊 Why don't other permissionless pools reduce their bond requirement to 2 ETH? +### 🐊 Why don't other permissionless pools reduce their bond requirement to 1 ETH? -> Reducing the bond requirement [increases node and staker risk](../docs/background/slash.md#liquid-staking-protocol-considerations) which Puffer mitigates through [Secure-Signer](tech/securesigner#what-is-it) and [Guardian support](../docs/arch/overview.md#guardians). +> Reducing the bond requirement [increases node and staker risk](slash.md#liquid-staking-protocol-considerations) which Puffer mitigates through [Secure-Signer](secure-signer.md#what-is-it) and [Guardian support](./guardians.md). Also as the bond requirement decreases, the threat of "rug-pooling" increases, which Puffer's [Validator Tickets](/protocol/validator-tickets#why--noop-incentives) address. ### 🪸 How hard is it to get access to SGX? -> Running Secure-Signer doesn't require anything expensive or technical, like purchasing and running an ASIC. Instead, Secure-Signer is software that runs on compatible Intel CPUs that support SGX. Many cloud providers (e.g., Microsoft Azure) readily supply SGX-enabled servers for cheap that are compatible with Secure-Signer. Additionally, Intel SGX-enabled XEON servers with the specs to run a validator can be purchased to be run at home. Community members have even had success running Secure-Signer on Intel NUCs! - +> Running Secure-Signer doesn't require anything expensive or technical, like purchasing and running an ASIC. Instead, Secure-Signer is software that runs on compatible Intel CPUs that support SGX. Many cloud providers (e.g., Microsoft Azure) readily supply SGX-enabled servers for cheap that are compatible with Secure-Signer. Additionally, Intel SGX-enabled XEON servers with the specs to run a validator can be purchased to be run at home. Community members have even had [success running Secure-Signer on Intel NUCs](https://mirror.xyz/ladislaus.eth/joTqwZ1sBLxlJayV4pIYxCkwl4RWheM_xipU_OCp9MM)! diff --git a/docs/glossary.md b/docs/glossary.md new file mode 100644 index 0000000..b81d687 --- /dev/null +++ b/docs/glossary.md @@ -0,0 +1,89 @@ +--- +title: Glossary +slug: /reference/glossary +--- + +### Glossary +### `Eigenlayer` +An Ethereum-based protocol that enables restaking + +### `AVS` +Actively Validated Service ~ the term for a service on Eigenlayer + +### `Restaking` +Where people reuse collateral to operate ≥ 1 AVS. If this collateral is beacon chain ETH, they are a called a `native restaker` + +### `LSP` +Liquid Staking Protocol + +### `nLRP` +Native Liquid Restaking Protocol. The Puffer protocol offers native ETH liquid restaking on Eigenlayer + +### `pufETH` +The yield bearing token that represents staked ETH in Puffer’s LSP + +### `Stakers` +The users who “stake” ETH to the pool to receive pufETH + +### `NoOps` +The Puffer nodes that operate an Ethereum validator (and optionally additional AVSs) + +### `Guardians` +A committee of Ethereum aligned community members and organizations to assist the protocol as it matures + +### `Enclave` +A secure-computing environment capable of running Puffer’s anti-slashing technology + +### `Burst Threshold` +Code in our smart contracts that self-caps the pool at 22% marketshare + +### `Puffer DAO (pDAO)` +Governance for the protocol controlled by the `PUFI` governance token + +### `Beacon Chain` +The main component of the Ethereum blockchain responsible for Proof of Stake consensus + +### `Beacon Chain Deposit Contract` +The smart contract to which a NoOp must deposit 32 ETH to initiate running a validator node + +### `VEM` +Voluntary Exit Message ~ a validator-signed message that will exit the signer when broadcasted to the beacon chain + +### `Withdrawal Credentials` +A validator parameter that sets where their consensus rewards and full withdrawal eth are sent. For 0x01 (post-Shapella) withdrawals, the credentials are formatted as `0x01000000000000` ++ `20 byte ethereum address` + +### `Consensus Rewards` +AKA partial withdrawals or skimmed rewards. These rewards are generated by Ethereum validators performing their PoS duties + +### `Execution Rewards` +The rewards earned by a validator when proposing a block. The rewards are composed of priority fees and MEV: Maximal Extractable Value". This refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. [source](https://ethereum.org/en/developers/docs/mev/) + +### `Full Withdrawal` +The validator’s entire balance that is withdrawn from the beacon chain to the Ethereum address set by the withdrawal credentials + +### `Slashing` +Slashing may refer to a loss of funds triggered by either of the following: +1. Misbehavior of validator nodes, such as signing two different blocks for the same beacon slot (AKA double-signing). See [secure-signer](technology/secure-signer) for more info on this kind of slashing +2. A Restaking Operator (ReOp) not fulfilling obligations defined by an AVS + +### `Validator Ticket` +An ERC20 token. Each Validator Ticket allows operating a validator on the Puffer Protocol for one day. + + +### `Bond` +An amount of pufETH a NoOp must lend to the protocol during the time of running their validator node. They may lose some or all of this bond if they misbehave or are slashed. NoOps may retrieve this bond after proving they have exited their validator node from the beacon chain + +### `Puffer Module` +A contract which defines a set of AVSs which NoOps opting into the module will delegate their ETH funds to running. These NoOps will receive corresponding rewards in return by participating in this Puffer Module + +### `Restaking Operator` +AKA ReOp: A NoOp that is delegated funds to operate an AVS on behalf of other NoOps, as part of a Puffer Module + +### `Secure Signer` +A software developed by Puffer that helps prevent validators from being slashed. It utilizes Trusted Execution Environments (TEEs) such as Intel SGX + +### `Proof of Reserves` +This refers to the process by which the protocol proves the amount of ETH backing pufETH, and thus determining the fair exchange ratio between ETH and pufETH + +### `Proof of Rewards` +This refers to the process by which NoOps prove and receive the rewards generated as a result of running their validator node \ No newline at end of file diff --git a/docs/governance.md b/docs/governance.md new file mode 100644 index 0000000..c4e7dfa --- /dev/null +++ b/docs/governance.md @@ -0,0 +1,8 @@ +--- +title: Governance +slug: /protocol/governance +--- + +:::caution Under Construction 🚧 +👷‍♂️ Puffer's governance is under construction ~ working with the brightest minds to design something resilient and decentralized 👷‍♀️ +::: \ No newline at end of file diff --git a/docs/guardians.md b/docs/guardians.md new file mode 100644 index 0000000..c671519 --- /dev/null +++ b/docs/guardians.md @@ -0,0 +1,35 @@ +--- +title: Guardians +slug: /protocol/guardians +--- +# Guardians + +:::info +The Puffer Protocol's Guardians are a group of trusted and permissioned nodes tasked with ensuring the stable operation of the protocol. While their presence serves a critical function, the intention is to render them obsolete as Ethereum's ecosystem evolves and specific EIPs are introduced. +::: + +## Who are the Guardians? + +The Guardians are a collective of respected community members who are deeply aligned with Ethereum's principles and values. These individuals, who function as a decentralized autonomous organization (DAO), have a vested interest in the protocol's success and the wider benefit of the Ethereum ecosystem. Their reputation within the community acts as a safeguard, ensuring they operate with the utmost integrity. + +## What are their duties? + +Guardians have two main responsibilities within the Puffer Protocol: + +1. **Proof of Reserves**: This involves reporting the amount of ETH backing pufETH to update the conversion rate. This ETH is comprised of active NoOp validators, full withdrawal ETH from any exited NoOps, restaking rewards owed to stakers, and the balance of the PufferVault. With the introduction of [**EIP-4788**](https://eips.ethereum.org/EIPS/eip-4788), this task will become automated and trustless via a Zero-Knowledge Proof (ZKP). + +2. **Ejecting validators**: Until [**EIP-7002**](https://eips.ethereum.org/EIPS/eip-7002) is realized, the protocol relies on the Guardians to eject validators under certain conditions. They use encrypted validator keyshares, stored in specialized enclaves designed solely to sign exit messages. A validator will be ejected if: + - Its beacon chain balance falls below below the DAO threshold. + - Its [module](/protocol/restaking-modules#restaking-modules-) was slashed due to an AVS violation. + - It consumes all of its validator tickets without renewal. + +A majority agreement among the Guardians (e.g., 7 out of 8) is required before any significant action is taken. + +## Roadmap to Decentralization + +Achieving full protocol-level decentralization is the end goal for Puffer. This would mean the protocol operates without any dependence on the core team, third parties, or external entities. Two Ethereum Improvement Proposals, **EIP-7002** and **EIP-4788**, are critical to this mission: + +- **EIP-7002**: Once implemented, it will render the Guardian's role in overseeing validator ejections obsolete as they can be triggered from a smart contract. +- **EIP-4788**: Allows for trustless trustless proof of reserves, removing the dependency on any trusted entity to report how much ETH is backing the pufETH Liquid Staking Token (LST). + +Until these EIPs are fully adopted, the Guardians serve as an interim measure. They allow the Puffer Protocol to grow and decentralize Ethereum safely, ensuring pooled stakers remain shielded from risks and uncertainties in the interim. The Guardians' role, although crucial now, is a temporary measure designed to safeguard staker assets and ensure protocol growth in Ethereum's constantly evolving landscape. \ No newline at end of file diff --git a/docs/guiding-principles.md b/docs/guiding-principles.md new file mode 100644 index 0000000..d6234be --- /dev/null +++ b/docs/guiding-principles.md @@ -0,0 +1,55 @@ +--- +title: Guiding Principles +slug: /protocol/guiding-principles +--- +:::info +Puffer aims to make Ethereum validating not just accessible but profitable 💪🐡 + +::: + +The protocol strives to improve Ethereum validator diversity. In this spirit, the Puffer Protocol was designed to be... + +### Safety first +> *The protocol must reduce staking and restaking risk for its stakers and the networks they are supporting.* + +- Puffer's NoOps run anti-slashing hardware and lock collateral to mitigate slashing risk. Learn more 👉 [Secure-Signer for slash protection](/technology/secure-signer). +- Puffer introduces a novel approach to validator collateral with better long-term NoOp incentives. Learn more 👉 [validator tickets incentives](/protocol/validator-tickets). +- Puffer uses a highly-aligned security counsel to reduce inactivity risk. Learn more 👉 [Guardian duties](/protocol/guardians#what-are-their-duties). +- Puffer places strict guardrails around which AVSs are allowed as the restaking ecosystem evolves. Learn more 👉 [restaking AVSs](/protocol/restaking-modules#restricting-avss). +- Puffer places strict guardrails around who can operate AVSs as the restaking ecosystem evolves. Learn more 👉 [restaking operators](/protocol/restaking-modules#restricting-reops). +- Puffer adjusts risk by allocating the protocol's ETH amongst different Eigenlayer AVSs and Restaking Operators. Learn more 👉 [allocating ETH to modules](/protocol/restaking-modules). + +### Ethos-aligned +> *The protocol must be aligned with Ethereum's ethos.* + +- Puffer is preemptively self-capping it's pool size to 22% to protect Ethereum's credible neutrality. Learn more 👉 [burst threshold to self-cap](/protocol/burst-threshold). +- Puffer is designed with a roadmap to complete decentralization. Learn more 👉 [decentralizing the Guardians](/protocol/guardians#roadmap-to-decentralization). +- Puffer helps increase Ethereum's Proof of Stake stability since NoOps have long-term commitments. Learn more 👉 [validator tickets](/protocol/validator-tickets#pros-and-cons). +- Puffer received an Ethereum Foundation grant for our anti-slashing technology. Learn more 👉 [Secure-Signer](https://blog.ethereum.org/2023/02/22/allocation-update-q4-22). + +### Permissionless +> *The protocol must allow anyone to run a validator.* + +- Puffer allows anyone with [enclave-compatible](/reference/glossary#enclave) hardware and 1 ETH to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/nodes/requirements). +- Puffer allows anyone with a 2 ETH bond (any hardware) to run an Ethereum validator. Learn more 👉 [NoOp Requirements](/nodes/requirements). + +### Low barriers +> *The protocol must be capital efficient to attract NoOps.* + +- Puffer reduces the ETH amount needed to become an Ethereum validator to as little as ETH, inviting more participants. Learn more 👉 [validator tickets](/protocol/validator-tickets). +- Puffer gives NoOps restaking exposure with less than 32 ETH. Learn more 👉 [modules](/protocol/restaking-modules). + +### Profitable +> *The protocol must be profitable to attract NoOps.* + +- Puffer allows NoOps to increase their profit margins through Eigenlayer restaking exposure. Learn more 👉 [modules](/protocol/restaking-modules). +- Puffer NoOps use [enclave-compatible](/reference/glossary#enclave) hardware to protect themselves from slashing while unlocking unique restaking opportunities, increasing their hardware efficiency. Learn more 👉 [Secure-Signer](/technology/secure-signer). + +### Scalable +> *The protocol must be scalable to compete with centralized liquid staking protocols.* + +- Puffer helps the protocol grow by allowing stakers to bring any amount of ETH. Learn more 👉 [minting pufETH](/stakers/minting-pufETH). +- Puffer supercharges rewards for pufETH holders through restaking exposure. Learn more 👉 [nLRTs](/protocol/nlrt). +- Puffer is designed so that pufETH can grow in value even if validator queues are very long. Learn more 👉 [validator tickets](/protocol/validator-tickets#pros-and-cons). +- Puffer stakers earn rewards even if the protocol's validators underperform. Learn more 👉 [NoOp incentives](/protocol/validator-tickets#why--noop-incentives). + diff --git a/docs/background/mergeshang.md b/docs/hardforks.md similarity index 87% rename from docs/background/mergeshang.md rename to docs/hardforks.md index 8e4d9d6..2e73639 100644 --- a/docs/background/mergeshang.md +++ b/docs/hardforks.md @@ -1,6 +1,6 @@ --- -sidebar_position: 1 title: Ethereum Proof of Stake +slug: /reference/ethereum-hard-forks --- ## The Merge @@ -16,10 +16,10 @@ Validators are incentivized to participate through consensus and execution rewar To ensure that validators perform honestly and diligently, Ethereum PoS enforces penalties. In the event of minor offenses (e.g., going offline), validators are penalized amounts equal to the rewards they would have received if they operated correctly. -In more serious cases, validators may be slashed, which removes them from the validator network and burns some or all of their bond. Slashing happens in response to [three specific offenses](background/slash.md), all of which cause validators to equivocate or send conflicting messages that cause disagreements and disarray in the consensus protocol. +In more serious cases, validators may be slashed, which removes them from the validator network and burns some or all of their bond. Slashing happens in response to [three specific offenses](slash.md), all of which cause validators to equivocate or send conflicting messages that cause disagreements and disarray in the consensus protocol. ## The Shapella Update The Merge succeeded in consolidating the main chain and Beacon Chain, but this was just a milestone in the larger plan to transition to PoS safely. Additional functionality will be added in future forks. -With the [Shanghai/Capella](https://notes.ethereum.org/@launchpad/withdrawals-faq) update, validators can now withdraw their ETH entirely. Additionally, validators enjoy more liquidity as consensus rewards in excess of 32 ETH will be partially withdrawn to an execution layer address approximately weekly. \ No newline at end of file +With the [Shanghai/Capella](https://notes.ethereum.org/@launchpad/withdrawals-faq) update, validators can now withdraw their ETH entirely. Additionally, validators enjoy more liquidity as consensus rewards in excess of 32 ETH will be partially withdrawn to an execution layer address approximately weekly. diff --git a/docs/intro.md b/docs/intro.md index 9f5ce60..ba7b02e 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -1,21 +1,91 @@ --- -sidebar_position: 1 +title: Hello Puffer 🐡 slug: / --- +> ### +:::info About Puffer +Puffer is a decentralized native liquid restaking protocol (nLRP) built on Eigenlayer 🐡🤝🟣 -# Puffer Introduction +It makes [native restaking](/protocol/restaking-modules/#native-restaking-) on [Eigenlayer](https://www.eigenlayer.xyz/) more accessible, allowing anyone to run an Ethereum Proof of Stake (PoS) validator while supercharging their rewards. +::: -## **More than a stake pool** -Puffer is much more than just a staking pool; it's a protocol that works to fortify Ethereum's heart. At its core, Ethereum's security and credible neutrality relies on a vast network of nodes. We're on a mission to ensure a thriving decentralized pocket amidst the broader validator set, making home-staking not just feasible but extraordinarily viable! +## What does Puffer bring? 🍽️ -With Puffer, you get more with less. We amplify nodes' capital efficiency through a reduced bond requirement of just 2 ETH, supercharging their economic potential with unique restaking services, and ensuring peak hardware efficiency and reduced risk using anti-slashing TEEs ([Secure-Signer](tech/securesigner.md)). +### **Protocol** -By leveraging these unique opportunities, Puffer is able to empower at-home nodes by providing a viable way for the Ethereum community to increase decentralization, and solidify Ethereum’s robustness, bolstering the overarching security of the network. +- 🟢 Permissionless: anyone can run a validator on Puffer. -As we continue to navigate the frontier of blockchain technology, and open up to a new wave of adoption, it remains increasingly important for liquid staking protocols (LSPs) to continue innovating. By introducing unique yield strategies, Puffer can empower at-home nodes and provide them with the necessary defences to ward off centralizing forces that pose a threat to Ethereum’s credible neutrality. +- 🥩 Native Restaking: the first native liquid restaking protocol on Eigenlayer. -## Mission -> Increase the viability of at-home validators +- 🧢 Ethos Alignment: the protocol is self-capped to protect Ethereum. -The Ethereum staking industry is in a race to the bottom, and the low-margin business of operating nodes is most easily filled by institutions, leading to centralization ([more on risks of LSTs](https://notes.ethereum.org/@djrtwo/risks-of-lsd)). Considering the high hardware costs and associated operating risks, becoming an at-home staker is not economically viable. Puffer aims to address this issue by mitigating the risks tied to Proof-of-Stake (PoS) operations, lowering the bond requirement, and offering additional reward opportunities by better utilizing hardware via unique restaking services. +- 🐡 Explosive Growth: pufETH can grow in value even if validator queues are long. + +### **NoOps** + +- 💯 Capital Efficiency: less than 2 ETH to run a validator. + +- 🐢 Slash Protection: first-of-its-kind anti-slashing hardware support. + +- 🎲 MEV Autonomy: NoOps choose their MEV strategy. + + +### **Rewards** + +- 💦 Liquid Staking: anyone can stake any ETH amount. + +- 🚀 Restaking Rewards: Eigenlayer integration supercharges rewards. + +- 🎟️ Validator Tickets: aligns NoOp incentives, smooths MEV, and creates new markets. + +- 💧 Liquid Rewards: NoOps' execution rewards are immediately liquid. + +- 😎 Buy and Hodl: Earn PoS and restaking rewards without running a validator. + +----- + +### The Puffer Flywheel 🎡 +
+ +![PufferFlywheel](/img/PufferFlywheel.png) +
+ +Together, stakers and NoOps create a flywheel effect that allows Puffer to outpace the growth of traditional liquid staking protocols. However, **to ensure that Puffer never becomes a threat to Ethereum's credible neutrality, the [burst threshold](protocol/burst-threshold) caps the Puffer at 22% of the validator set**. + + +The protocol is driven by **Stakers** and **Node Operators** (NoOps): +- **NoOps** can join *any* Puffer [module](/protocol/restaking-modules) by locking [Validator Tickets](/protocol/validator-tickets) and 1 ETH as collateral. In exchange, they get to operate a 32 ETH validator and keep 100% of its PoS rewards until they run out of VTs. NoOps can boost their rewards by joining [restaking](/reference/glossary#Restaking) modules and delegating the validator's ETH to a [restaking operator](/protocol/restaking-modules#restaking-operators) in exchange for restaking rewards commission. + + +- **Stakers** can deposit any amount of ETH to help fund the protocol's 32 ETH NoOp-controlled validators. In exchange, they receive the pufETH [native Liquid Restaking Token](/protocol/nlrt#what-is-an-lst) (nLRT) which grows in value as the protocol mints validator tickets and receives restaking rewards. + +### Why be a NoOp? 🤖 +Anyone with less than 2 ETH can run their own validator to earn sustainable PoS rewards while helping to decentralize Ethereum. NoOps can get restaking exposure for additional rewards without requiring the 32 ETH to become a native restaker, allowing them to earn several times more than they could as a solo validator. + +:::tip +Puffer has the best capital efficiency for a permissionless liquid staking protocol and this extends to restaking. +::: + +NoOps are entitled to **100% of their validators' [execution rewards](/reference/glossary#execution-rewards)**. This means they get to decide their MEV strategy which helps strengthen Ethereum's censorship-resistance and [can be very lucrative in some cases](https://etherscan.io/block/17806773#mevinfo). + +NoOps also receive **100% of their validators' [consensus rewards](/reference/glossary#consensus-rewards)**, meaning their validator's profitability depends solely on themselves, incentivizing for excellent long-term NoOp performance. + +NoOp collateral is converted to pufETH during registration, allowing them to earn additional passive rewards throughout their commitment. + +### Why stake with Puffer? 🥩 +Compared to most liquid staking protocols, stakers on Puffer no longer have to trust validators to have good performance for pufETH to earn competitive rewards. Rather validator tickets provide stakers with guaranteed rewards regardless of the validators' long-term performance. + +:::tip +pufETH accrues PoS rewards immediately instead of relying on NoOp's long-term performance. +::: + +Instead of waiting for PoS rewards to slowly accrue, pufETH holders receive rewards each time validator tickets are minted. This dynamic favors early stakers as pufETH can quickly appreciate from all future minted validator tickets, even if the beacon chain's validator queue is extremely congested. + +Traditional liquid staking tokens (LSTs) only accrue PoS rewards. As a nLRT, pufETH accrues both PoS and restaking rewards, allowing a staker to earn more without requiring complicated DeFi strategies. However, pufETH is a liquid token and therefore is 100% compatible with DeFi for those that value composability. + +Puffer prioritizes the safety of stakers' ETH. To ensure staked ETH is safe, the protocol requires: +- NoOps to lock 1 ETH of collateral and run [Puffer’s anti-slashing technology](/technology/secure-signer) for defense-in-depth or lock 2 ETH of collateral without the anti-slasher +- [Eject validators](/protocol/guardians#what-are-their-duties) whose balance falls too low +- Guardrails around [which AVSs are allowed](/protocol/restaking-modules#restricting-avss) +- Guardrails around who can become a [restaking operator](/protocol/restaking-modules#restricting-reops) diff --git a/docs/joining/_catagory_.json b/docs/joining/_catagory_.json deleted file mode 100644 index 7cfd494..0000000 --- a/docs/joining/_catagory_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Joing the Puffer Pool", - "position": 5 - } - \ No newline at end of file diff --git a/docs/joining/noop.md b/docs/joining/noop.md deleted file mode 100644 index d38b546..0000000 --- a/docs/joining/noop.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -sidebar_position: 3 -title: Node Operators ---- - -To register as a Node Operator (NoOp) and spin up a validator instance at Puffer Pool you would follow these steps: - -## Joining - -- NoOp running Secure-Signer saves a fresh validator key to its encrypted and persistent enclave - memory. (Intel SGX for now) - -- NoOp performs Remote Attestation committing to a validator key. - -- NoOp submits attestation evidence (with RAVE, another product of Puffer, stay tuned) and 2 ETH to permissionless NoOp onboarding contract. - -- Onboarding contract verifies the key was generated by Secure-Signer, pairs the NoOp with 30 - Staker ETH, and registers the Puffer Pod in the beacon deposit contract. - -- pufETH is minted for the 2 ETH NoOp bond but is locked. - -- The NoOp performs validator duties on behalf of the Pod, earning consensus and execution - rewards. - -- Secure-Signer prevents the NoOp from accidentally signing slashable material. - -## Exiting - -- NoOp would submit their voluntary exit message to the pool. - -- NoOp will receive their bond in ETH. diff --git a/docs/joining/stakers.md b/docs/joining/stakers.md deleted file mode 100644 index 1537f76..0000000 --- a/docs/joining/stakers.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -sidebar_position: 2 -title: Stakers ---- - -## Joining - -To stake ETH on Puffer and receive pufETH (Pufffer's LSD), you simply need to connect your wallet and mint pufETH with as low as 0.01 ETH. - -Your pufETH will accrue in value over time and it will increase in value per the Pool's APR. - -You can also stake pufETH on other DeFi platforms to earn more yield. - -Example: - -- If you staked 1 ETH, you will receive 1 pufETH. - -- With an APR of 10%, your ETH would increase and your wallet will show 1.1 pufETH after some time. - -## Exiting - -Simply connect your wallet on Puffer's website, burn pufETH, and claim ETH. diff --git a/docs/modules.md b/docs/modules.md new file mode 100644 index 0000000..b40f0b9 --- /dev/null +++ b/docs/modules.md @@ -0,0 +1,69 @@ +--- +title: Restaking Modules +slug: /protocol/restaking-modules +--- + +:::info +Puffer allows Validators to get native restaking exposure to earn more than they could in traditional liquid staking protocols or solo staking. +::: + + +### Native restaking 🥩 +A *native restaker* is an Ethereum PoS validator that restakes their 32 ETH to operate Eigenlayer [AVSs](https://docs.eigenlayer.xyz/overview/key-terms). Native restakers are awarded AVS fees in exchange for their service, but are subject to penalties if they break the AVS's rules. To engage in native restaking, validators must point their [withdrawal credentials](/reference/glossary/#withdrawal-credentials) to an [EigenPod](https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/core/EigenPodManager.md#eigenpodmanager) contract which then opts-in to restaking and chooses its AVSs. + +Native restaking allows validators to better utilize their ETH capital and hardware to supplement their PoS rewards. However, the 32 ETH requirement is too high a barrier for most to participate. Additionally, some AVSs may require far greater computational requirements than what is expected from PoS. Puffer aims to address this through its restaking modules. + +### Restaking Modules 🐡 +At its core, the Puffer protocol is a collection of **RestakingModule** contracts. Each module controls an EigenPod that functions as a single native restaker but is composed of *many* NoOp-controlled validators. + +
+ +![PufferModule](/img/PufferModule.png) + +
+ +Modules are filled with the validators of NoOps whose sole job is to perform Ethereum PoS validation. If the module engages in restaking, the validator ETH is restaked and used as collateral for the AVSs that the module is committed to. During Puffer's initial phase, the responsibility of operating the AVSs is delegated to a DAO-chosen [**restaking operator**](/protocol/restaking-modules#restaking-operators) (ReOp), who provides the service in exchange for a portion of the generated AVS fees. + +The protocol decides which AVSs the modules are assigned, allowing restaked ETH to be allocated to AVSs according to the protocol's risk preferences. Pictured above, the `EigenDA + AltLayer` AVS set has the most modules servicing it compared to the `EigenDA` or `Drosera` AVS sets. + +Given the delegation risk, the NoOps are awarded commission on the AVS fees with the rest returned to the protocol, helping grow the value of pufETH. This allows NoOps with less than 2 ETH to earn rewards from native restaking. Risk-averse NoOps can choose the default module which will not engage in restaking or delegation. + +:::tip +When NoOps deploy their validators to restaking modules they automatically earn restaking rewards commission. +::: + +### Restaking Operators +Restaking Operators (ReOps) are operators whose job is to perform all the required AVS duties on behalf of a given restaking module. ReOps may also be NoOps within their own or other modules. ReOps are expected to perform well to maximize restaking rewards for their own benefit and that of the NoOps in their module and pufETH holders downstream. + +### Joining a module 👈 +To hold strong to our alignment to Ethereum's ethos, it is **always permissionless** for NoOps to join a module and deploy an Ethereum validator. + +:::tip +It is permissionless for NoOps to deploy validators to modules. +::: + +To join, NoOps lock [1 or 2 ETH](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node) collateral and lock [validator tickets](/protocol/validator-tickets#what), which represent a long-term commitment to run a validator in the module. Their collateral is then locked as pufETH and they are provisioned 32 ETH to deploy their validator to the module's [EigenPod](https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/core/EigenPodManager.md#eigenpodmanager) contract. + +The NoOp is now entitled to keep all of the PoS rewards (consensus and execution) generated by their validator. The NoOps that joined restaking modules will also receive restaking rewards. + +## Restaking risks and mitigations 🚧 +The concept of restaking, while promising, introduces certain inherent risks to stakers and NoOps alike. These primarily revolve around the vulnerabilities of smart contracts and potential AVS slashing risks. + +:::tip +Puffer strives to mitigate these risks by taking a conservative approach as restaking matures. +::: + +Through the sustainable rewards that it can offer, restaking can reshape the dynamics of the liquid staking market, which is currently on a dangerous path towards complete centralization. + + +### Restricting ReOps + +To ensure a safe transition into the world of restaking, Puffer will rely more heavily on governance to decide restaking qualifications during its nascent stages. During this time, only reputable ReOps with excellent performance that have been selected through governance will be eligible to operate the AVSs on behalf of a given module. + +As Eigenlayer, AVSs, and Puffer’s anti-slashing mechanisms mature, proven NoOps will have the option to become ReOps without DAO-approval. + +### Restricting AVSs + +As an open platform, Eigenlayer allows anyone to deploy an AVS. Thus, allowing restaking modules to service any AVS would expose the stakers and NoOps to too much slashing risk. + +To mitigate this risk, Puffer requires the DAO to onboard new modules, carefully vet the allowed AVSs, and manage the allocation of modules to AVSs. \ No newline at end of file diff --git a/docs/nlrt.md b/docs/nlrt.md new file mode 100644 index 0000000..8e8e08d --- /dev/null +++ b/docs/nlrt.md @@ -0,0 +1,72 @@ +--- +title: native Liquid Restaking Tokens (nLRTs) +slug: /protocol/nlrt +--- + +:::info +Think of nLRTs as version 2.0 of LSTs 🤯 +::: + +### What is an LST? + +Liquid Staking Tokens (LSTs) represent staked ETH in a tokenized format, providing liquidity to stakers while their ETH remains locked on the beacon chain. Through LSTs, stakers passively earn PoS rewards without needing to operate a validator. These tokens offer multiple benefits: + +- **Liquidity**: By staking ETH, users receive a tradable token that can be used in various DeFi activities. +- **Ease of Use**: Rewards accrue to LSTs automatically without requiring actions by the staker. +- **Flexibility**: With LSTs, users can participate in a wide range of DeFi protocols, multiplying potential yield avenues. + +### Introducing native Liquid Restaking Tokens (nLRTs) + +Ethereum's constantly evolving staking landscape has given rise to a new token model: the **native Liquid Restaking Token (nLRT)**. This modern take on liquid staking provides a unique advantage over its predecessor, the LST. + +:::tip +Fundamentally, an nLRT is an LST that delivers traditional PoS rewards and boosts these with additional restaking rewards. +::: + +### How do nLRTs Differ from LRTs? + +nLRTs generate their restaking rewards through [native restaking](https://docs.eigenlayer.xyz/restaking-guides/restaking-user-guide/#liquid-vs-native-restaking) on Eigenlayer, where Ethereum PoS validator ETH is the staked asset. This sets them apart from Liquid Restaking Tokens (LRTs). An LRT tokenizes restaked LSTs within a Liquid Restaking Protocol (LRP). While the LRP yields rewards from restaking services, these are distinct from PoS rewards. + +Although the core concept aligns with LSTs, LRTs focus solely on rewards from restaking services. At Puffer, we've observed that LRTs might intensify the [decentralization challenges](https://twitter.com/dannyryan/status/1688644951230267392?s=46&t=bsdBaPIHlTHEWDDdVUJW4g) associated with LSTs in Ethereum. In constrast, nLRTs actively promote decentralization, integrating new validators into PoS while also enhancing their profitability. Importantly, this is why Puffer has been dedicated to launching with a permissionless validator set from day one. + +### pufETH + +pufETH is implemented as a reward-bearing ERC20 token, following in the footsteps of [Compound's cToken](https://docs.compound.finance/v2/ctokens/#ctokens) design for optimal DeFi compatibility. It represents a novel approach in the liquid staking domain, introducing several features that enhance stakers' rewards and interaction with DeFi protocols. + +#### **Enhanced Reward Potential** +nLRTs, including pufETH, provide a diversified stream of rewards. They encompass both traditional Ethereum PoS rewards, but have another dimension by allowing holders to earn rewards from restaking services. This dual-source reward system positions nLRT holders to potentially outearn their LST counterparts. + +#### **Value Acceleration with Validator Tickets** +pufETH uniquely leverages [validator tickets](/protocol/validator-tickets#overview) to fast-track its value growth. By frontloading Ethereum PoS rewards, it not only increases the immediate claim of the pufETH token, but also creates compelling incentives for both short-term and long-term participation. + +#### **Decoupling from Validator Performance** +Unlike LSTs, where rewards are closely tied to the performance of associated validators, pufETH provides a layer of insulation. It ensures that stakers receive PoS rewards independent of the validators' performance, leading to more stable and predictable returns and mitigating the impact of any potential underperformance. + +#### **Seamless DeFi Integration with Enhanced Simplicity** +Within the burgeoning LSDeFi ecosystem, the adaptability of staking mechanisms to mesh seamlessly with a wide array of protocols is of utmost importance. While LSTs have set a standard in offering DeFi compatibility, pufETH elevates this experience. + +Unlike the two-step process of holding an LST and then restaking it into an LRP to earn restaking rewards, with pufETH, users achieve this with a single step. By merely holding onto pufETH, they inherently tap into restaking rewards. This streamlining ensures that stakers can maximize the utility and rewards of their staked assets without compromising on the flexibility and opportunities traditional LSTs offer in DeFi. + +### How pufETH Works +Stakers deposit ETH at the PufferPool contract to the mint pufETH nLRT. At the protocol's inception, pufETH's conversion rate is one-to-one, but is updated daily when the protocol performs [proof of reserves](/protocol/guardians#what-are-their-duties). Assuming the protocol performs well, i.e., accrues more rewards than penalties, the amount of ETH reedamable for pufETH will increase between growth spurts. + +#### Calculating the Conversion Rate +The conversion rate can be calculated simply as: + +
+ +`conversion rate = (deposits + rewards - penalties) / pufETH supply` +
+ +- `deposits` and `pufETH supply` increase proportionally as stakers deposit ETH to mint pufETH, leaving the `conversion rate` unaffected. + +- `rewards` increase as [restaking operators](/protocol/restaking-modules#restaking-operators) run AVSs and whenever validator tickets are minted. + +- `penalties` accrue if validators are slashed on PoS for *more than their $1$ ETH* collateral, which is [disincentivized behavior](/protocol/validator-tickets#why--noop-incentives) and mitigated through [anti-slashing technology](/technology/secure-signer). Penalties can also accrue if the restaking operator is slashed running AVSs, which is why Puffer is [restricting restaking operator participation](/protocol/restaking-modules#restricting-reops) during its nascent stages. + +#### Example +At the protocol’s inception, Bob stakes $10$ ETH and receives $10$ pufETH. Then, after some time, the protocol earns $2$ ETH of rewards by minting validator tickets and restaking. Now Bob’s $10$ pufETH is backed by $12$ ETH, making the conversion rate $\frac{10+2-0}{10}=1.2$ ETH per pufETH. + +Assuming Charlie decides to stake $1$ ETH, he would mint $\frac{1}{1.2} = 0.83$ pufETH due to the increased conversion rate. Since Charlie deposited instead of adding rewards, the conversion rate remains unchanged at $\frac{11 + 2 - 0}{10.83} = 1.2$ ETH per pufETH. + +Bob can redeem his $10$ pufETH for $10*1.2=12$ ETH, given there is enough liquidity in the PufferVault and the daily withdrawal limit has not been reached. \ No newline at end of file diff --git a/docs/overview.md b/docs/overview.md new file mode 100644 index 0000000..702b090 --- /dev/null +++ b/docs/overview.md @@ -0,0 +1,64 @@ +--- +title: Overview +slug: /protocol/overview +--- + +:::info +Puffer is a native liquid restaking protocol (nLRP) designed to harness the power of restaking. +::: + + +## Puffer Walkthrough 👩‍🏫 + +
+ +![PufferFlywheel](/img/PufferProtocol.png) +
+ +### 0️⃣ Creating Restaking Modules +The protocol starts with a default [module](/protocol/restaking-modules#puffer-modules-) that only allows for PoS validating and cannot engage in restaking, which is considered the "risk-free" module for NoOps. Over time, new restaking modules will be added. + +Puffer governance plays a crucial role in overseeing modules, including adding new modules and managing their AVS commitments. + +For example, adding a new module to the PufferProtocol contract requires governance to: +1. Vet and select the [restaking operator](/protocol/restaking-modules#restricting-reops) to run the module. +2. Vet and [select the Eigenlayer AVSs](/protocol/restaking-modules#restricting-avss) that the module should service. + +--- +### 1️⃣ Staking ETH +Stakers can deposit ETH and mint the [pufETH nLRT](/protocol/nlrt#pufeth) via the PufferPool contract, which serves as a redeemable receipt for their restaked ETH. If sufficient exit liquidity is available, stakers can reclaim their ETH from the PufferVault. Over time, the redeemable amount is expected to increase from [validator tickets](/protocol/validator-tickets) and restaking rewards. +Stakers can deposit ETH and mint the [pufETH nLRT](/protocol/nlrt#pufeth) via the PufferPool contract, which serves as a redeemable receipt for their staked ETH. If sufficient exit liquidity is available, stakers can reclaim their ETH from the PufferVault. Over time, the redeemable amount is expected to increase from selling [validator tickets](/protocol/validator-tickets) and restaking rewards. + +In [contrast with conventional liquid staking tokens (LSTs)](/protocol/nlrt#what-is-an-lst), pufETH can provide strictly more rewards for its holders. Not only does pufETH encompass PoS rewards **and** restaking rewards, but its value can accelerate quickly due to validator ticket sales. Furthermore, the PoS rewards for stakers are decoupled from the protocol validators' performance. + +--- +### 2️⃣ Registering a NoOp Validator +To register a new validator, NoOps deposit [validator tickets](/protocol/validator-tickets) and [1 or 2 ETH](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node) as collateral to the PufferProtocol contract. In return, the protocol mints pufETH, which remains locked until it's confirmed that their validator has successfully exited. Locking pufETH serves to: +- Align NoOp incentives +- Safeguard staker ETH +- Increase NoOp profit margins + +To ensure the safety of stakers, NoOps must distribute their encrypted validator keyshares to the Guardians' [enclaves](/reference/glossary#enclave), allowing them to eject the NoOps if their validator balance falls too low or they run out of validator tickets. This requirement is to protect stakers and it will be [upgraded to a trustless solution](/protocol/guardians#roadmap-to-decentralization) once Ethereum's protocol allows it via [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002). + +--- +### 3️⃣ Provisioning ETH +Each RestakingModule contract will contain a queue of pending NoOp registrations. As the PufferPool accrues 32 ETH chunks from deposits and rewards, the Guardians will provision the chunks to the NoOps' pending validators, following a round-robin schedule to ensure all of the protocol's modules are serviced. + +The provisioning step will create a new validator within the EigenPod whose ETH can be natively restaked on Eigenlayer to serve as collateral for its registered AVS. For this reason, the NoOp's validator's [withdrawal credential](/reference/glossary#withdrawal-credentials) is required to the module's EigenPod contract. After provisioning, the NoOp's validator will have deposited 32 ETH to the [BeaconDepositContract](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa) and will await activation. + +--- +### 4️⃣ PoS Rewards +Once their validator activates, the NoOp is eligible to validate for as many days as validator tickets they have deposited. Throughout this duration, the NoOp keeps 100% of the generated PoS rewards. Their [execution rewards](/reference/glossary#execution-rewards) are immediately deposited to their wallets, while their [consensus rewards](/reference/glossary#consensus-rewards) accrue in the module's EigenPod and can be withdrawn following the [NoOp withdrawal process](/nodes/rewards). + +Since NoOps receive 100% of the PoS rewards they generate, they are [incentivized](/protocol/validator-tickets#why--noop-incentives) to maximize their validator performance, helping protect staker ETH. + +--- + +### 5️⃣ Restaking Rewards +Restaking operators execute the AVSs on the module's behalf and receive a commission for their services. The accumulated fees from these AVSs enhance the value of pufETH. This mechanism allows stakers to achieve higher returns compared to conventional LSTs. + +By participating in a restaking module, NoOps bear additional risks to their collateral. To compensate, they are granted a portion of the restaking rewards. This arrangement allows them to earn more rewards than through PoS alone, without the need for additional hardware or computational resources. They can access these rewards periodically, using the same [NoOp withdrawal process](/nodes/rewards) as for consensus rewards. + +--- +### ️6️⃣ Exiting Validators +When a NoOp wishes to exit the protocol, they must first ensure their associated validator has exited the beacon chain. Once they present verifiable proof of their validator's exit, the contract tallies any penalties related to inactivity or slashing that the validator might have incurred. The corresponding pufETH amount, equivalent to the ETH penalties, is burned from the NoOp's locked collateral and the remainder is returned to the NoOp. This process ensures that stakers are appropriately compensated for any potential ETH losses that might have occurred during the validator lifecycle. Additionally, any unused validator tickets will be returned to the NoOp. \ No newline at end of file diff --git a/docs/tech/rave.md b/docs/rave.md similarity index 99% rename from docs/tech/rave.md rename to docs/rave.md index 52bcc9d..33e5f3b 100644 --- a/docs/tech/rave.md +++ b/docs/rave.md @@ -1,6 +1,6 @@ --- -sidebar_position: 2 title: RAVe +slug: /technology/RAVe --- RAVe is the second component of Puffer's Ethereum Foundation grant and stands for `Remote Attestation Verification`. This essential set of smart contracts allows enclaves to interface with blockchains securely and helps let the Puffer Pool be permissionless. RAVe enables entirely [new use cases](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462) that weren't previously possible that we are excited to explore at Puffer. diff --git a/docs/rewards.md b/docs/rewards.md new file mode 100644 index 0000000..c277329 --- /dev/null +++ b/docs/rewards.md @@ -0,0 +1,50 @@ +--- +title: Rewards +slug: /protocol/rewards +--- + +:::info +Stakers and NoOps can earn more due to native restaking. +::: + +### Rewards Overview +The protocol receives rewards from the [validator tickets](/protocol/validator-tickets#what) minted to run validators and from [restaking rewards](/protocol/restaking-modules) generated by [restaking operators](/protocol/restaking-modules#restaking-operators) as they operate [AVSs](/reference/glossary#avs). Together, these rewards increase the amount of ETH backing pufETH, [increasing the conversion rate](/protocol/nlrt#how-pufeth-works) between the two and thus the value of pufETH. This section will outline how rewards are distributed among the protocol's participants. + +### Who Gets Rewards? +#### **Stakers** +- They earn PoS and restaking rewards by holding the [pufETH nLRT](/protocol/nlrt). + +#### **NoOps** +- They get [all the PoS rewards](/protocol/validator-tickets#noop-incentives) their validators make. +- They earn more by [holding pufETH](/protocol/overview#2%EF%B8%8F⃣-registering-a-noop-validator) and from deploying their validators in [restaking modules](/protocol/restaking-modules#joining-a-module-). + +#### **Restaking Operators** +- They get a [fee](/protocol/overview#5%EF%B8%8F⃣-restaking-rewards) for running AVSs on behalf of [restaking modules](/protocol/restaking-modules#restaking-operators). + +#### **Guardians** +- They get fees for doing [their jobs](/protocol/guardians#what-are-their-duties) and to help with their gas costs. + +#### **Puffer Protocol** +- It gets a fee to support its growth and to give the governance token more [utility](/protocol/governance). + +### Rewards Breakdown +#### Consensus Rewards +Due to validator tickets, **NoOps receive 100% of consensus rewards**. These consensus rewards are directed to the [withdrawal credentials](/reference/glossary#withdrawal-credentials) which will, in this case, be the [module's EigenPod](/protocol/restaking-modules#restaking-modules-). However, these rewards are not immediately accessible for withdrawal. After a delay, NoOps can withdraw their consensus rewards using a [merkle rewards tree](/nodes/rewards). + +#### Execution Rewards +Thanks to validator tickets, **NoOps also receive 100% of execution rewards**. This arrangement grants NoOps full control over their MEV (Maximal Extractable Value) strategy, without any mandatory software constraints such as [MEV-Boost](https://github.com/flashbots/mev-boost), allowing for potentially more censorship resistance. Execution rewards are immediately liquid as they are routed automatically to the NoOps' specified wallet using their own `fee_recipient` address. + +#### Restaking Rewards +Restaking rewards are the fees derived from operating AVSs. While some protocols, like EigenDA, remit their payments in ETH and are straightforward to manage, others might use ERC20 tokens for payment. In such cases, these ERC20 rewards must be converted into ETH before being distributed to the Puffer protocol's participants. + +:::caution EigenLayer Specs not finalized 🚧 +EigenLayer is in active development with more detailed information regarding AVS payments coming soon. +::: + +#### **Validator Tickets** +[Validator Tickets](/protocol/validator-tickets) cost ETH to mint and are allocated as follows: +- Guardians are paid a fee to incentivize honest behavior and cover gas-fees. +- The treasury is allocated a portion as a protocol fee. +- Stakers get the remainder deposited to the PufferVault. + +--- \ No newline at end of file diff --git a/docs/tech/securesigner.md b/docs/secure-signer.md similarity index 96% rename from docs/tech/securesigner.md rename to docs/secure-signer.md index 0dfc5ee..d739d2c 100644 --- a/docs/tech/securesigner.md +++ b/docs/secure-signer.md @@ -1,6 +1,6 @@ --- -sidebar_position: 2 title: Secure-Signer +slug: /technology/secure-signer --- Puffer's Secure-Signer is a remote signing tool backed by an [Ethereum Foundation grant](https://blog.ethereum.org/2023/02/22/allocation-update-q4-22) designed to prevent slashable offenses using Intel SGX. @@ -13,14 +13,14 @@ TEEs provide confidentiality and integrity guarantees. In the context of SGX, an ## Where is it run? -| ![](img/mevboost.png) | +| ![](/img/mevboost.png) | | :---------------------------------------------------------------------------------------------: | | Secure-Signer in the validator tech stack. Adapted from https://github.com/flashbots/mev-boost | Secure-Signer is a remote-signing tool that manages validator keys on behalf of the consensus client. It can run locally with the consensus client or on a remote server. From the point of view of a node operator, there is little difference in setting up their validator. If they have SGX-enabled hardware, they can install and run Secure-Signer and instruct their consensus client of choice to use Secure-Signer as the remote-signer. ## How does it prevent slashing? -![](img/secure-signer.png) +![](/img/secure-signer.png) To prevent possible slashes through double-signing, the Secure-Signer generates and safeguards all BLS validator keys inside its encrypted and tamper-proof memory. These keys can only be accessed during runtime and remain encrypted at rest, making them inaccessible to the node unless used to sign non-slashable block proposals or attestations. diff --git a/docs/background/slash.md b/docs/slash.md similarity index 97% rename from docs/background/slash.md rename to docs/slash.md index c64dbea..246cde3 100644 --- a/docs/background/slash.md +++ b/docs/slash.md @@ -1,43 +1,44 @@ --- -sidebar_position: 2 title: Penalties in Ethereum PoS +slug: /reference/slashing-in-PoS --- ## Validator Stack + Each validator is responsible for safeguarding a `validator key` to perform their consensus duties. This key will be used to sign off on blocks and attestations to receive execution and consensus rewards. How does the validator actually perform these duties? A validator must run the necessary tech stack before they can sign anything. This includes an `execution client`, which executes the transactions they receive to update their perceived state of the Ethereum chain. The most popular execution clients are [Geth](https://github.com/ethereum/go-ethereum), [Besu](https://github.com/hyperledger/besu), [Nethermind](https://github.com/NethermindEth/nethermind), and [Erigon](https://github.com/ledgerwatch/erigon). They will also run a `consensus client,` which facilitates the communication between validator peers to agree on a shared state. The consensus client ultimately uses the validator key to sign PoS-related messages. The main consensus clients include [Teku](https://github.com/ConsenSys/teku), [Nimbus](https://github.com/status-im/nimbus-eth2/), [Lodestar](https://github.com/ChainSafe/lodestar), [Prysm](https://github.com/prysmaticlabs/prysm/), and [Lighthouse](https://github.com/sigp/lighthouse). - ## Slashing in Ethereum PoS + Slashing occurs when a validator equivocates or sends conflicting messages within the validator network. There are [three ways this can happen](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/): - + > - By proposing and signing two different blocks for the same Slot > - By attesting to a block that ”surrounds” another one (effectively changing history) > - By ”double voting” by attesting to two candidates for the same block Common causes of slashing occur when a validator key is shared across multiple consensus clients, causing conflicting signatures (e.g., attesting two different blocks within the same slot and creating a fork). While this may occur accidentally, the network cannot differentiate this behavior from an attack on the consensus protocol and thus discourages this through slashing. While potentially devastating for a validator's collateral, slashing can be avoided by simply remaining consistent with their previously signed blocks and attestations. -In practice, this is done by maintaining a history of previously signed material (e.g., [EIP-3076](https://eips.ethereum.org/EIPS/eip-3076)) within the consensus client or externally in a [Remote-Signer](https://github.com/ConsenSys/web3signer). Before the validator key signs any block proposals or attestations, the consensus client or remote-signer will first check its previously signed material for any conflicts. +In practice, this is done by maintaining a history of previously signed material (e.g., [EIP-3076](https://eips.ethereum.org/EIPS/eip-3076)) within the consensus client or externally in a [Remote-Signer](https://github.com/ConsenSys/web3signer). Before the validator key signs any block proposals or attestations, the consensus client or remote-signer will first check its previously signed material for any conflicts. While this technique reduces the risk of slashing events, there are instances in which the remote-signer is vulnerable. For example, a validator may be slashed if its validator key is shared amongst multiple remote-signers or due to a bug in the consensus client. Additionally, a slash may happen if the validator’s EIP-3076 slash protection database is accidentally or maliciously corrupted. -Check out [Secure-Signer](tech/securesigner.md) to find out how Puffer prevents slashing. - +Check out [Secure-Signer](secure-signer.md) to find out how Puffer prevents slashing. ## Slashing penalties -The Ethereum PoS specifications introduce the notion of an [anti-correlation penalty](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-anti-correlation-penalties-in-eth2). To disincentivize validator collusion, the slashing penalty is proportional to the number of validators that were slashed within approximately 18 days. More concretely, if any of the three slashing offenses are breached, the validator will lose $1 + \frac{3s}{D} * 32$ ETH, where $s$ is the amount of ETH slashed within 18 days, and $D$ is the total amount of ETH staked on Ethereum. + +The Ethereum PoS specifications introduce the notion of an [anti-correlation penalty](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-anti-correlation-penalties-in-eth2). To disincentivize validator collusion, the slashing penalty is proportional to the number of validators that were slashed within approximately 18 days. More concretely, if any of the three slashing offenses are breached, the validator will lose $1 + \frac{3s}{D} * 32$ ETH, where $s$ is the amount of ETH slashed within 18 days, and $D$ is the total amount of ETH staked on Ethereum. For low-correlation slashing events (e.g., user error), a validator will lose close to the 1 ETH minimum, but for high-correlation events (e.g., consensus client bug), they could lose their full 32 ETH. See this [article](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) for more information. The existence of slashable offenses and the large penalty increase risk and motivate Puffer's Secure-Signer. ## Inactivity Penalties + The rule of thumb is that offline validators will lose approximately as much as they would have made by being online and doing their duties. There are some caveats. This applies to consensus rewards and does not take into account the money that could have been made if they missed a block proposal. Additionally, this does not consider [inactivity leaks](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties). In the case of an inactivity leak, a validator will lose increasingly more ETH as a penalty until the chain can reach finality. If the protocol had taken months to years to eject an inactive validator, the inactivity leak mechanism would expedite this to days to weeks. This poses a risk in permissionless pools and motivates Puffer's architecture. - ## Liquid Staking Protocol Considerations > ### Slashing Risk @@ -54,4 +55,4 @@ In the case of an inactivity leak, a validator will lose increasingly more ETH a > Currently, the only way to withdraw a validator is by signing a VoluntaryExit message (VEM) with the validator key. In a permissioned pool where nodes are trusted, the problem of getting them to sign a VEM is easy; however, the node may go offline or refuse to sign the VEM in a permissionless pool. -> This has been the key hurdle in reducing the bond requirement. Modifications to the PoS specs to [allow for smart-contract-triggered-ejections](https://github.com/ethereum/EIPs/pull/7002) have been drafted but are not ready to be added a hard fork. This valuable time could allow centralized staking operations to take market share from permissionless pools by outcompeting in terms of capital efficiency. \ No newline at end of file +> This has been the key hurdle in reducing the bond requirement. Modifications to the PoS specs to [allow for smart-contract-triggered-ejections](https://github.com/ethereum/EIPs/pull/7002) have been drafted but are not ready to be added a hard fork. This valuable time could allow centralized staking operations to take market share from permissionless pools by outcompeting in terms of capital efficiency. diff --git a/docs/tech/_catagory_.json b/docs/tech/_catagory_.json deleted file mode 100644 index 260a24c..0000000 --- a/docs/tech/_catagory_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Puffer Pool Technology", - "position": 3 - } - \ No newline at end of file diff --git a/docs/validator-tickets.md b/docs/validator-tickets.md new file mode 100644 index 0000000..9d23162 --- /dev/null +++ b/docs/validator-tickets.md @@ -0,0 +1,116 @@ +--- +title: Validator Tickets +slug: /protocol/validator-tickets +--- + +:::info +Validator Tickets are Puffer's novel addition to the validator lifecycle in LSTs. +::: + +**Validator Tickets** are the evolution to Puffer's initial "[Smoothing Commitment](https://ethresear.ch/t/validator-smoothing-commitments/17356)" research collaboration with [Justin Drake](https://twitter.com/drakefjustin), and are closely related to the recent "[Execution Tickets](https://ethresear.ch/t/execution-tickets/17944)" proposal that was [added to Ethereum's roadmap](https://x.com/VitalikButerin/status/1741190491578810445?s=20). + +### Overview + +
+ +![Minting VTs](/img/mint-vt.png) +
+ +The idea is simple but powerful: +> +- **pufETH**: People stake their ETH and receive pufETH, a token representing their staked ETH within the Puffer protocol, which is used to fund Ethereum validators. +- **Validator Tickets (VTs)**: VTs are ERC20 tokens that grant the holder the right to run a staker-funded Ethereum validator for a day. VTs are minted by ETH deposits. This ETH goes towards compensating pufETH holders for financing validators. +- **Running Validators**: To run a validator, a node operator must lock VTs and lock in 1 ETH of pufETH as collateral. +- **Pricing VTs**: The price of a VT is set based on the expected daily earnings from running a validator, with a discount to incentivize purchases. This price directly influences the expected pufETH APR. +- **Benefits**: VTs create new trading opportunities, address “rug-pooling”, and incentivize good performance. pufETH holders earn rewards immediately when VTs are purchased. Consuming VTs allows the node operator to keep 100% of the validator’s earnings. + +:::tip +Before EigenLayer restaking is live, selling VTs is pufETH's source of rewards. +::: + + + + +### The status quo +Typically, Liquid Staking Protocols (LSPs) use two methods for validators: + +- **Unbonded Model**: Validators don't need to lock up collateral. This is good for growth but risky because penalties affect the staking pool, and it often requires specially approved validators (permissioned / KYC). + +- **Bonded Model**: Validators lock collateral for their operation period. This method is more secure and allows for *any* validator to join, but slows LSP growth as it requires a large amount of ETH upfront per validator. + +Puffer uses the *bonded model* as it is more ethos-aligned, but adds VTs to address some of its shortcomings. + +### How are VTs used? +
+ +![Using VTs](/img/using-vt.png) +
+ +**Validator Tickets** supplement validator bonds. When registering a validator, the NoOp locks 1 ETH worth of pufETH as a bond and deposits at least 28 VTs. + +In exchange, they are allocated 32 ETH to run a validator, and are entitled to 100% of the Proof of Stake (PoS) rewards they produce over as many days as VTs they've deposited. In other words, NoOps pay pufETH holders ETH upfront to run a validator. + +:::tip +For stakers, this means the value of pufETH increases every time a VT is minted. +::: + +Each VT represents one validator-day of expected Proof of Stake (PoS) rewards. The payments to mint VTs directly pay pufETH holders, creating strong growth dynamics. This mechanism is favorable for stakers, capital efficient, and incentivizes for optimal NoOp performance. Upon exiting a validator, the number of locked VT tokens, corresponding to the number of days the validator was active, will be burned and the remaining locked VTs are released back to the NoOp as a refund. + + + +### Why? ~ NoOp Incentives +The success of an LSP largely depends upon the performance of its NoOps. Traditionally, having NoOps deposit collateral has been a method to ensure alignment with the protocol's objectives. The logic is simple: with a financial stake in play, NoOps have a deterrent against going offline, suffering slashing penalties, or engaging in nefarious activities like MEV theft ("*rug-pooling*"). If they were to engage in such activities, they'd stand to lose their collateral. + +While this collateral approach discourages penalties, it does not strongly incentivize performance. For instance, a "lazy" NoOp could alternate between being online and offline, ensuring their validator balance stays at 32 ETH. This strategy results in no reward generation for the LSP, but also no collateral loss for the NoOp. + +Puffer changes this incentive landscape through the use of VTs. Since NoOps have already purchased VTs, they stand to gain nothing from underperforming since they cannot recoup this initial payment, even if they maintain their validator balance. Thus, for a NoOp to turn a profit, they must perform at least on par with the average validator. Those who excel can earn even more. + +While VTs provide strong disincentives for slashing, to further protect the staker's ETH, Puffer requires a [1 or 2 ETH](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node) bond and for NoOps to use [anti-slashing technology](/technology/secure-signer) for defense-in-depth. + +This new approach neatly tackles two traditional problems: +- *Rug-pooling*: With NoOps entitled to all the MEV they generate, there's no longer a need to police or penalize them for rug-pooling. +- *Lazy NoOps*: Since stakers get a proxy for PoS rewards upfront via minting VTs, they aren't adversely affected if a NoOp underperforms. + +### Requirements +For PoS stability and NoOp incentive alignment, [1 or 2 ETH](/reference/faq#%EF%B8%8F-how-many-eth-do-i-need-to-run-a-puffer-node) worth of pufETH and a minimum of 28 VTs are required to be deposited at registration time. Their duration begins at the moment their validator is activated on the beacon chain, and each VT represents 1 day or 255 epochs. + +Assuming they deposited 28 VTs, after 28 days of validating, the NoOp's validator will be automatically ejected, its 32 ETH returned to the protocol, and bond returned. If they wish to extend their duration, NoOps can deposit additional VTs at any time. Validators with unconsumed VTs (e.g deposited 100 VTs) that exit after the 28 days will be refunded (e.g., 72 VTs). + + +### Pricing Validator Tickets +During Puffer's Phase 1, VT prices will be posted by the [Guardians](/protocol/guardians#). The prices are calculated with the following formula, where $R_{expected}$ is the expected daily validator revenue based on historical consensus and execution rewards, and $D$ is a discount rate: + +
+ +$P_{VT} = R_{expected} * (1 - D)$ +
+ +**Example** +- Assuming the expected [consensus](/reference/glossary#consensus-rewards) and [execution](/reference/glossary#execution-rewards) rewards from running a validator for a year is $5\% * 32 = 1.6$ ETH. +- A simplified $R_{expected}$ can be calculated as $1.6 / 365 = 0.00438$ ETH. +- Given a discount $D = 10\%$, the VT price is $P_{VT} = 0.00438 * 90\% = 0.00394$ ETH. +- A NoOp that pays $P_{VT}$ is expected to earn on average $R_{expected} = 0.00438$ ETH by consuming the VT to run a validator for a day. +- The result is $0.00438 * 10\% = 0.000438$ ETH profit. Note, the $R_{expected}$ depends on factors like the NoOp's performance, validator set size, and MEV conditions. + + +### Pros and Cons +**Pros**: +- **Capital Efficiency**: By requiring just $1$ ETH collateral and VTs, NoOps can get started with less than 2 ETH, which is significantly less than traditional LSPs. This capital-efficient approach means that barriers to entry are reduced, enabling a broader range of participants to contribute to securing the network without having to commit a full 32 ETH. + +- **Fuels Growth**: The VT model is a game-changer for LSPs. It ensures that the LSP continues to earn rewards *even when the validator queue is long*. In traditional setups, lengthy validator queues could stifle an LSP's ability to grow, but with VTs, this obstacle is greatly diminished. + +- **No More Rug-Pooling Oversight**: The previous need to constantly watch over and penalize rug-pooling activities added overhead and complexity that may only be solvable with in-protocol solutions like [MEV-Burn](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029). With NoOps entitled to 100% of the execution rewards they generate, this oversight becomes unnecessary, simplifying operations. + +- **Addresses Lazy NoOps**: Traditional bonded models do not fully disincentivize NoOps from denying the pool rewards by going offline frequently. With VTs, NoOps are naturally incentivized to perform their best since their upfront payment cannot be recouped through subpar performance. + +- **Slash Resistant**: +With a combination of just 1 ETH collateral, favorable NoOp incentives, and Puffer's [anti-slashing technology](/technology/secure-signer), the risk of staker ETH getting penalized from an irresponsible NoOp is considerably reduced. + +- **MEV Lottery**: NoOps can participate in the MEV lottery, an attractive proposition for many, without having to lock up 32 ETH. This opens the door for more NoOps to benefit from potential MEV gains, further incentivizing participation. + +**Cons** +- **Novelty**: VTs introduce a new paradigm in the staking industry. While innovation can be beneficial, it also comes with the challenge of gaining trust amidst established practices. + +- **Increased Capital**: VTs requires more upfront ETH compared to just having a bond. Yet, this concern is substantially offset as Puffer offers the lowest bond ($1$ ETH) among all permissionless LSPs, making the added ETH requirement relatively small in the overall context. + +- **Pricing VTs**: Although PoS rewards maintain stability, they are influenced by market dynamics (execution rewards) and fluctuations in the validator set size (consensus rewards). However, since VTs are equal to a validator-day and are repriced daily, volatility is mitigated. Additionally, VTs are liquid and can be traded on the secondary market. \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index 252076a..36af5f3 100644 --- a/sidebars.js +++ b/sidebars.js @@ -22,31 +22,29 @@ const sidebars = { "intro", { type: "category", - label: "Background", - items: ["background/mergeshang", "background/slash"], + label: "Protocol", + items: [ + "overview", + "guiding-principles", + "nlrt", + "modules", + "validator-tickets", + "rewards", + "guardians", + "burst-threshold", + "governance", + ], }, { type: "category", label: "Technology", - items: ["tech/securesigner", "tech/rave"], + items: ["secure-signer", "rave"], }, { type: "category", - label: "Protocol", - items: [ - "arch/overview", - // "arch/pufeth", - // "arch/mev", - // "arch/ejection", - // "arch/governance", - ], + label: "Reference", + items: ["glossary", "hardforks", "slash", "faq"], }, - // { - // type: "category", - // label: "Joining Puffer Pool", - // items: ["joining/stakers", "joining/noop"], - // }, - "faq" ], }; diff --git a/static/img/PufferFlywheel.png b/static/img/PufferFlywheel.png new file mode 100644 index 0000000..bc95ab7 Binary files /dev/null and b/static/img/PufferFlywheel.png differ diff --git a/static/img/PufferModule.png b/static/img/PufferModule.png new file mode 100644 index 0000000..448ed5a Binary files /dev/null and b/static/img/PufferModule.png differ diff --git a/static/img/PufferProtocol.png b/static/img/PufferProtocol.png new file mode 100644 index 0000000..def48ab Binary files /dev/null and b/static/img/PufferProtocol.png differ diff --git a/static/img/Puffer_Growth_Spurt.png b/static/img/Puffer_Growth_Spurt.png new file mode 100644 index 0000000..7f73966 Binary files /dev/null and b/static/img/Puffer_Growth_Spurt.png differ diff --git a/static/img/RewardsAPR.png b/static/img/RewardsAPR.png new file mode 100644 index 0000000..b1fa706 Binary files /dev/null and b/static/img/RewardsAPR.png differ diff --git a/static/img/RewardsDistribution.svg b/static/img/RewardsDistribution.svg new file mode 100644 index 0000000..028c468 --- /dev/null +++ b/static/img/RewardsDistribution.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/static/img/favicon.ico b/static/img/favicon.ico deleted file mode 100644 index 1e5a690..0000000 Binary files a/static/img/favicon.ico and /dev/null differ diff --git a/docs/tech/img/mevboost.png b/static/img/mevboost.png similarity index 100% rename from docs/tech/img/mevboost.png rename to static/img/mevboost.png diff --git a/static/img/mint-vt.png b/static/img/mint-vt.png new file mode 100644 index 0000000..e7189c9 Binary files /dev/null and b/static/img/mint-vt.png differ diff --git a/docs/tech/img/secure-signer.png b/static/img/secure-signer.png similarity index 100% rename from docs/tech/img/secure-signer.png rename to static/img/secure-signer.png diff --git a/static/img/smoothing-commitment.png b/static/img/smoothing-commitment.png new file mode 100644 index 0000000..f58d2de Binary files /dev/null and b/static/img/smoothing-commitment.png differ diff --git a/static/img/smoothing-commitment2.png b/static/img/smoothing-commitment2.png new file mode 100644 index 0000000..4e19378 Binary files /dev/null and b/static/img/smoothing-commitment2.png differ diff --git a/static/img/using-vt.png b/static/img/using-vt.png new file mode 100644 index 0000000..1f8b483 Binary files /dev/null and b/static/img/using-vt.png differ