From 1aa8a5d57a74fb6ac7adf32405d61896497e974a Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Mon, 8 Apr 2024 09:47:24 +0300 Subject: [PATCH 01/20] Fix link's relative path --- content/guides/getstarted/full-stack-solana-development.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/getstarted/full-stack-solana-development.md b/content/guides/getstarted/full-stack-solana-development.md index 4de420166..533105f45 100644 --- a/content/guides/getstarted/full-stack-solana-development.md +++ b/content/guides/getstarted/full-stack-solana-development.md @@ -963,7 +963,7 @@ Let's give them a front-end to do that. #### Program deploy failed? Program code is temporarily stored in -[buffer accounts](docs/programs/deploying#state-accounts) while programs are +[buffer accounts](/docs/programs/deploying#state-accounts) while programs are being deployed. You can view and close these accounts with: ```shell From 8ea72e130fa90b36032d8b3d85eedca09c34b5c8 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Mon, 2 Dec 2024 17:57:41 +0200 Subject: [PATCH 02/20] Add the DePin guide --- content/guides/depin/getting-started.md | 202 ++++++++++++++++++++++++ content/guides/depin/index.md | 4 + 2 files changed, 206 insertions(+) create mode 100644 content/guides/depin/getting-started.md create mode 100644 content/guides/depin/index.md diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md new file mode 100644 index 000000000..9c13a9a37 --- /dev/null +++ b/content/guides/depin/getting-started.md @@ -0,0 +1,202 @@ +--- +featured: false +featuredPriority: 1 +date: 2024-12-02T00:00:00Z +difficulty: beginner +seoTitle: "DePIN Quickstart Guide" +title: "DePIN Quickstart Guide" +description: + "While each DePIN network has a unique product focus, most DePIN networks + utilize Solana for a common set of use-cases. This guide is meant to help + builders get oriented to common onchain DePIN use-cases." +keywords: + - DePIN + - token + - governance +tags: + - depin + - governance + - zk compression +--- + +While each DePIN network has a unique product focus, most DePIN networks utilize +Solana for a common set of use-cases. This guide is meant to help builders get +oriented to these common onchain DePIN use-cases: + +- Minting and Managing a Token +- Rewards Distribution +- Proof of Contribution +- Governance + + +This guide is serves as a general overview. There are many nuances beyond what +is covered here to consider for your specific network and application. + + +## Minting and Managing a Token + +### Token Minting + +When minting a token on Solana, there are two token programs to choose from, +[the Token program](https://spl.solana.com/token) or +[the Token22 program](https://spl.solana.com/token-2022). While there are +tradeoffs to consider, discussed +[here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old), +to date, most DePIN teams have elected to use +[the Token program](https://spl.solana.com/token). + +### Token Listing + +In order to have your token appear in explorers, decentralized exchanges, and +other ecosystem token lists, +[getting the token verified through Jupiter Verification](https://station.jup.ag/guides/general/get-your-token-on-jupiter) +is recommended. + +### Modeling Token Distribution + +For DePIN teams looking to optimize the way they allocate their token across +various needs and stakeholders (rewards for participating / supplying network +resources, private or public tokens ales etc.), tools like +[Forgd](https://www.forgd.com/) can be used to model out and refine token +distribution strategies. + +### Token Management + +Most teams utilize [Squads](https://squads.so/) for their on-chain treasury +management, also leveraging their multisig feature. + +## Rewards Distribution + +There are two common paths for rewards distributions. Each of these optimize the +cost of distributing a potentially small value of tokens to a large set of users +by allowing the application to do so in a single transaction per claim period. + +### Merkel Claims + +Rewards can be distributed using a Merkle tree structure, allowing for efficient +batch processing of claims. This approach is used to minimize the number of +transactions on the blockchain by allowing users to claim their rewards based on +a published Merkle root. + +The application constructs a Merkel tree on a regular basis and publishes the +root on-chain. Each leaf node represents a recipient’s rewards. + +In order for users to claim their rewards, they generate a Merkle proof that +demonstrates a particular leaf is part of the published Merkle root. Once their +claim is verified, the rewards are distributed to the user’s wallet. + +See +[example code](https://gist.github.com/catalinred/45fae83177f5dc5d0c9a8b083c0653aa), +and +[Jupiter’s merkle distributor](https://github.com/jup-ag/merkle-distributor-sdk) +as an additional reference. + +#### Automatic Distribution + +An alternative to having users proactively claim rewards is to have a separate +process to automate the process of distributing rewards. On a regular basis, +this “rewards crank” fetches rewards for an associated set of users by querying +and constructing transactions to distribute rewards to the specified accounts. +Merkle tree updates can be posted by the automated process, allowing the reward +distribution mechanism to remain permissionless. + +### ZK Compression + +For networks that anticipate needing to distribute rewards to tens of thousands +(or more) of nodes/participants/contributors, a newer approach to rewards +distribution is to use [ZK compression](https://www.zkcompression.com/). Instead +of regular accounts, compressed accounts are generated for reward recipients, +minimizing the state and rent costs associated with account creation. + +Implementing ZK compression is often cheaper in terms of storage costs. However, +because is a relatively new feature, the level of ecosystem support and tooling +is not yet as extensive. + +See +[example code](https://gist.github.com/catalinred/4188158779bef27c70428e171e018694). + +#### Cost analysis + +Let's estimate the cost of distributing rewards using both the Merkle tree +approach and the ZK compression. We'll consider transaction fees, rent costs, +and storage costs. + +Transaction Fees may be higher using ZK compression due to the increased +computational resources and instructions needed. However, in both approaches, +updating the rewards per claim period requires a single transaction by the +application, so this cost difference is minimal as it doesn’t scale per the +number of users. Both strategies require one transaction per user to claim their +rewards. + +ZK compression is more cost-effective in storage costs, due to the reduced +storage requirements of compressed data. Here is a hypothetical cost analysis to +compare the storage costs. + +If we assume a reward distribution to 10,000 users, with an average reward +amount per user of 100 tokens, a transaction fee on Solana to be 0.000005 SOL +(5,000 lamports) + +Storage Costs using a Merkle tree distribution strategy: + +- The Merkle tree requires storing the leaf nodes and the internal nodes. + - Leaf Nodes: 10,000 \* 32 bytes = 320,000 bytes + - Internal Nodes: (2^14 - 1) \* 32 bytes = 524,256 bytes + - Total Storage Cost: (320,000 + 524,256) \* 0.00000348 SOL/byte (per epoch) = + 2.94 SOL +- Total Cost (Merkle Tree): 0.050005 SOL + 0.00007323 SOL + 2.94 SOL = 2.99 SOL + +Storage Costs using a ZK compression distribution strategy: + +- Compressed Token Account: The compressed token account stores the compressed + reward data. + - Compressed Data Size: Assuming a compression ratio of 50%, the total + compressed data size would be approximately 500 KB. + - Total Storage Cost: 500 _ 1024 _ 0.00000348 SOL/byte (per epoch) = 1.78 SOL +- Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 + SOL + +## Proof of Contribution + +DePIN networks generally need a way to prove the contribution that the the +nodes/contributors are being incentivized to provide. The application needs a +method of verifying that the nodes provided the resource in question, whether it +be wireless connectivity, GPU access, mapping data, geolocation data, etc., that +they are being rewarded to provide, honestly and consistently. + +Having the contributions be reported through Solana allows for using the +security properties inherent to Solana in order to allow the secure validation +of contribution. For example, we can leverage Solana allowing for consensus by a +number of validators who each independently verify computations during +transaction execution. The public nature of transactions allows for transparency +that can be used to create a higher level of economic security. + +While almost all DePIN networks require this proof-of-contribution in some form, +the exact mechanism can vary significantly from protocol to protocol. A number +of teams are building tooling to help DePIN projects aid in the abstraction of +this: +[Proof of Location by Witness Chain](https://docs.witnesschain.com/depin-coordination-layer/proof-of-location-testnet/introduction), +[Proof of Coverage by Helium](https://docs.helium.com/iot/proof-of-coverage). + +## Governance + +DePIN protocols tend to follow a path of measured, gradual decentralization that +over time shifts the decision-making around the protocol to onchain governance +by token holders. This could take the form of a social framework like a +[DAO,](https://www.realms.today/) or leverage +[liquid restaking](https://docs.fragmetric.xyz/fragsol/). + +For examples, see +[Modular Governance by Helium](https://docs.helium.com/governance/staking-with-helium-vote/) +or +[Network Governance by Hivemapper](https://docs.hivemapper.com/welcome/network-governance). + +## Migrations + +If you are a DePIN builder who has historically only been familiar with building +on EVM, not to worry! A number of large DePIN teams who began on EVM chains have +successfully migrated to Solana (see RNDR, Geodnet, and Xnet, amongst others). +There are +[specific resources to help developers make the transition from EVM to SVM](https://solana.com/developers/evm-to-svm). +Bridge infrastructure like +[Wormhole’s NTT](https://wormhole.com/products/native-token-transfers) +streamline the process of shifting your tokens to Solana. diff --git a/content/guides/depin/index.md b/content/guides/depin/index.md new file mode 100644 index 000000000..15fde103d --- /dev/null +++ b/content/guides/depin/index.md @@ -0,0 +1,4 @@ +--- +metaOnly: true +title: DePIN +--- From 15577c7c57a6950e0c19f884c713e9b42834c399 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Tue, 3 Dec 2024 10:42:12 +0200 Subject: [PATCH 03/20] Spelling and other small details --- content/guides/depin/getting-started.md | 115 ++++++++++++------------ 1 file changed, 57 insertions(+), 58 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 9c13a9a37..c7c95d823 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -19,31 +19,33 @@ tags: - zk compression --- +DePIN (Decentralized Physical Infrastructure Network) refers to blockchain-based +networks that incentivize the deployment, operation, and sharing of real-world +physical infrastructure through decentralized mechanisms. These networks +leverage tokens to reward participants for contributing to and maintaining the +infrastructure, creating a decentralized alternative to traditional centralized +systems. Examples include wireless, content delivery, and mapping networks. + While each DePIN network has a unique product focus, most DePIN networks utilize -Solana for a common set of use-cases. This guide is meant to help builders get -oriented to these common onchain DePIN use-cases: +Solana for a common set of use cases. This guide is meant to help builders get +oriented to these common on-chain DePIN use cases. Topics covered include: - Minting and Managing a Token - Rewards Distribution - Proof of Contribution - Governance - -This guide is serves as a general overview. There are many nuances beyond what -is covered here to consider for your specific network and application. - - ## Minting and Managing a Token ### Token Minting -When minting a token on Solana, there are two token programs to choose from, +When minting a token on Solana, there are two token programs to choose from: [the Token program](https://spl.solana.com/token) or [the Token22 program](https://spl.solana.com/token-2022). While there are -tradeoffs to consider, discussed -[here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old), -to date, most DePIN teams have elected to use -[the Token program](https://spl.solana.com/token). +tradeoffs to consider (discussed +[here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)), +most DePIN teams have elected to use +[the Token program](https://spl.solana.com/token) to date. ### Token Listing @@ -56,7 +58,7 @@ is recommended. For DePIN teams looking to optimize the way they allocate their token across various needs and stakeholders (rewards for participating / supplying network -resources, private or public tokens ales etc.), tools like +resources, private or public token sales etc.), tools like [Forgd](https://www.forgd.com/) can be used to model out and refine token distribution strategies. @@ -67,18 +69,19 @@ management, also leveraging their multisig feature. ## Rewards Distribution -There are two common paths for rewards distributions. Each of these optimize the -cost of distributing a potentially small value of tokens to a large set of users -by allowing the application to do so in a single transaction per claim period. +There are two common paths for rewards distributions: Merkle claims and ZK +compression. Each of these optimize the cost of distributing a potentially small +value of tokens to a large set of users by allowing the application to do so in +a single transaction per claim period. -### Merkel Claims +### Merkle Claims Rewards can be distributed using a Merkle tree structure, allowing for efficient batch processing of claims. This approach is used to minimize the number of transactions on the blockchain by allowing users to claim their rewards based on a published Merkle root. -The application constructs a Merkel tree on a regular basis and publishes the +The application constructs a Merkle tree on a regular basis and publishes the root on-chain. Each leaf node represents a recipient’s rewards. In order for users to claim their rewards, they generate a Merkle proof that @@ -86,36 +89,36 @@ demonstrates a particular leaf is part of the published Merkle root. Once their claim is verified, the rewards are distributed to the user’s wallet. See -[example code](https://gist.github.com/catalinred/45fae83177f5dc5d0c9a8b083c0653aa), +[example code](https://gist.github.com/lanvidr/88a594da06ba867bf8201fe8c6331dc0) and -[Jupiter’s merkle distributor](https://github.com/jup-ag/merkle-distributor-sdk) -as an additional reference. +[Jupiter’s Merkle distributor](https://github.com/jup-ag/merkle-distributor-sdk) +for an additional reference. #### Automatic Distribution -An alternative to having users proactively claim rewards is to have a separate -process to automate the process of distributing rewards. On a regular basis, -this “rewards crank” fetches rewards for an associated set of users by querying -and constructing transactions to distribute rewards to the specified accounts. -Merkle tree updates can be posted by the automated process, allowing the reward -distribution mechanism to remain permissionless. +An alternative to having users proactively claim rewards is automating rewards +distribution. On a regular basis, this “rewards crank” fetches rewards for an +associated set of users by querying and constructing transactions to distribute +rewards to the specified accounts. Merkle tree updates can be posted by the +automated process, allowing for the reward distribution mechanism to remain +permissionless. ### ZK Compression For networks that anticipate needing to distribute rewards to tens of thousands -(or more) of nodes/participants/contributors, a newer approach to rewards +(or more) of nodes, participants, or contributors, a newer approach to rewards distribution is to use [ZK compression](https://www.zkcompression.com/). Instead of regular accounts, compressed accounts are generated for reward recipients, minimizing the state and rent costs associated with account creation. Implementing ZK compression is often cheaper in terms of storage costs. However, -because is a relatively new feature, the level of ecosystem support and tooling -is not yet as extensive. +because it is a relatively new feature, the level of ecosystem support and +tooling is not yet as extensive. See -[example code](https://gist.github.com/catalinred/4188158779bef27c70428e171e018694). +[example code](https://gist.github.com/lanvidr/4595f7b02236ffb2a3fb3ce9347ca044). -#### Cost analysis +### Cost analysis Let's estimate the cost of distributing rewards using both the Merkle tree approach and the ZK compression. We'll consider transaction fees, rent costs, @@ -124,7 +127,7 @@ and storage costs. Transaction Fees may be higher using ZK compression due to the increased computational resources and instructions needed. However, in both approaches, updating the rewards per claim period requires a single transaction by the -application, so this cost difference is minimal as it doesn’t scale per the +application, so the cost difference is minimal, as it doesn’t scale per the number of users. Both strategies require one transaction per user to claim their rewards. @@ -133,12 +136,12 @@ storage requirements of compressed data. Here is a hypothetical cost analysis to compare the storage costs. If we assume a reward distribution to 10,000 users, with an average reward -amount per user of 100 tokens, a transaction fee on Solana to be 0.000005 SOL -(5,000 lamports) +amount per user of 100 tokens, and the transaction fee on Solana to be 0.000005 +SOL (5,000 lamports): Storage Costs using a Merkle tree distribution strategy: -- The Merkle tree requires storing the leaf nodes and the internal nodes. +- The Merkle tree requires storing the leaf nodes and the internal nodes - Leaf Nodes: 10,000 \* 32 bytes = 320,000 bytes - Internal Nodes: (2^14 - 1) \* 32 bytes = 524,256 bytes - Total Storage Cost: (320,000 + 524,256) \* 0.00000348 SOL/byte (per epoch) = @@ -148,41 +151,37 @@ Storage Costs using a Merkle tree distribution strategy: Storage Costs using a ZK compression distribution strategy: - Compressed Token Account: The compressed token account stores the compressed - reward data. + reward data - Compressed Data Size: Assuming a compression ratio of 50%, the total - compressed data size would be approximately 500 KB. + compressed data size would be approximately 500 KB - Total Storage Cost: 500 _ 1024 _ 0.00000348 SOL/byte (per epoch) = 1.78 SOL - Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL ## Proof of Contribution -DePIN networks generally need a way to prove the contribution that the the -nodes/contributors are being incentivized to provide. The application needs a -method of verifying that the nodes provided the resource in question, whether it -be wireless connectivity, GPU access, mapping data, geolocation data, etc., that -they are being rewarded to provide, honestly and consistently. - -Having the contributions be reported through Solana allows for using the -security properties inherent to Solana in order to allow the secure validation -of contribution. For example, we can leverage Solana allowing for consensus by a -number of validators who each independently verify computations during -transaction execution. The public nature of transactions allows for transparency -that can be used to create a higher level of economic security. - -While almost all DePIN networks require this proof-of-contribution in some form, -the exact mechanism can vary significantly from protocol to protocol. A number -of teams are building tooling to help DePIN projects aid in the abstraction of -this: +DePIN networks generally need a way to prove the contribution from network +participants. The application needs a method of verifying that participants have +provided the resource in question honestly and consistently. + +Reporting the contributions through Solana makes it possible to use the +blockchain’s inherent security properties to enable the secure validation of the +contribution. The public nature of transactions on the blockchain allows for +transparency that can be used to create a higher level of economic security. + +While almost all DePIN networks require proof-of-contribution in some form, the +exact mechanism can vary significantly from protocol to protocol. A number of +teams are building tooling to help DePIN projects develop their proof of +contribution models: [Proof of Location by Witness Chain](https://docs.witnesschain.com/depin-coordination-layer/proof-of-location-testnet/introduction), [Proof of Coverage by Helium](https://docs.helium.com/iot/proof-of-coverage). ## Governance DePIN protocols tend to follow a path of measured, gradual decentralization that -over time shifts the decision-making around the protocol to onchain governance -by token holders. This could take the form of a social framework like a -[DAO,](https://www.realms.today/) or leverage +shifts decision-making for the protocol to on-chain governance by token holders +over time. This could take the form of a social framework like a +[DAO](https://www.realms.today/) or leverage [liquid restaking](https://docs.fragmetric.xyz/fragsol/). For examples, see From 2eb8d4e55af6ea5f3b2c4712da2498412b6cb6de Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:11:48 +0200 Subject: [PATCH 04/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index c7c95d823..7ed193398 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -41,7 +41,7 @@ oriented to these common on-chain DePIN use cases. Topics covered include: When minting a token on Solana, there are two token programs to choose from: [the Token program](https://spl.solana.com/token) or -[the Token22 program](https://spl.solana.com/token-2022). While there are +[the Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to consider (discussed [here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)), most DePIN teams have elected to use From c250f66e213b1f3c81febf96ace2701fdd2657b0 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:12:00 +0200 Subject: [PATCH 05/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 7ed193398..145f6398d 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -43,7 +43,7 @@ When minting a token on Solana, there are two token programs to choose from: [the Token program](https://spl.solana.com/token) or [the Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to consider (discussed -[here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)), +[here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)). most DePIN teams have elected to use [the Token program](https://spl.solana.com/token) to date. From 217e8694b41c1df3f620f96c237a49868ec59107 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:12:22 +0200 Subject: [PATCH 06/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 145f6398d..cb0539490 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -44,8 +44,7 @@ When minting a token on Solana, there are two token programs to choose from: [the Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to consider (discussed [here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)). -most DePIN teams have elected to use -[the Token program](https://spl.solana.com/token) to date. +The recommended selection between the two options ultimately reduces to whether the features in the token extensions program would be of use to the application. ### Token Listing From 29db23a4eccadbe9b115bbc21421d9c33888d318 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:12:30 +0200 Subject: [PATCH 07/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index cb0539490..5d42718f2 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -123,8 +123,7 @@ Let's estimate the cost of distributing rewards using both the Merkle tree approach and the ZK compression. We'll consider transaction fees, rent costs, and storage costs. -Transaction Fees may be higher using ZK compression due to the increased -computational resources and instructions needed. However, in both approaches, +In both approaches, updating the rewards per claim period requires a single transaction by the application, so the cost difference is minimal, as it doesn’t scale per the number of users. Both strategies require one transaction per user to claim their From be181582b8d1cc925948d845153ce2db8ace0255 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:12:40 +0200 Subject: [PATCH 08/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 5d42718f2..e5223a9e5 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -134,8 +134,8 @@ storage requirements of compressed data. Here is a hypothetical cost analysis to compare the storage costs. If we assume a reward distribution to 10,000 users, with an average reward -amount per user of 100 tokens, and the transaction fee on Solana to be 0.000005 -SOL (5,000 lamports): +amount per user of 100 tokens, and the transaction fee on Solana to be 0.000007 +SOL (7,000 lamports): Storage Costs using a Merkle tree distribution strategy: @@ -152,9 +152,20 @@ Storage Costs using a ZK compression distribution strategy: reward data - Compressed Data Size: Assuming a compression ratio of 50%, the total compressed data size would be approximately 500 KB - - Total Storage Cost: 500 _ 1024 _ 0.00000348 SOL/byte (per epoch) = 1.78 SOL + - Total Storage Cost: 500 * 1024 * 0.00000348 SOL/byte (per epoch) = 1.78 SOL - Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL + + We can extrapolate this across different numbers of reward distributions. + +| Number of Distributions | Merkle Tree Storage Cost (SOL) | ZK Compression Storage Cost (SOL) | +|-------------------------|--------------------------------|-----------------------------------| +| 1,000 | 0.06 | 0.03 | +| 10,000 | 0.58 | 0.29 | +| 100,000 | 5.80 | 2.90 | +| 1,000,000 | 58.00 | 29.00 | +| 5,000,000 | 290.00 | 145.00 | + ## Proof of Contribution From 05eb30e078e8f2908fc52e474a669b5f5ba35706 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:13:03 +0200 Subject: [PATCH 09/20] Update content/guides/depin/getting-started.md Co-authored-by: lanvidr <51134415+lanvidr@users.noreply.github.com> --- content/guides/depin/getting-started.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index e5223a9e5..135535703 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -175,8 +175,7 @@ provided the resource in question honestly and consistently. Reporting the contributions through Solana makes it possible to use the blockchain’s inherent security properties to enable the secure validation of the -contribution. The public nature of transactions on the blockchain allows for -transparency that can be used to create a higher level of economic security. +contribution. While almost all DePIN networks require proof-of-contribution in some form, the exact mechanism can vary significantly from protocol to protocol. A number of From 905362cd35bea79e0a0c66fc88bb3596d955c96f Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Thu, 5 Dec 2024 15:21:27 +0200 Subject: [PATCH 10/20] Run prettier --- content/guides/depin/getting-started.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 135535703..6128ad6e5 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -41,10 +41,11 @@ oriented to these common on-chain DePIN use cases. Topics covered include: When minting a token on Solana, there are two token programs to choose from: [the Token program](https://spl.solana.com/token) or -[the Token22 program](https://spl.solana.com/token-2022). There are -tradeoffs to consider (discussed +[the Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to +consider (discussed [here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)). -The recommended selection between the two options ultimately reduces to whether the features in the token extensions program would be of use to the application. +The recommended selection between the two options ultimately reduces to whether +the features in the token extensions program would be of use to the application. ### Token Listing @@ -123,11 +124,10 @@ Let's estimate the cost of distributing rewards using both the Merkle tree approach and the ZK compression. We'll consider transaction fees, rent costs, and storage costs. -In both approaches, -updating the rewards per claim period requires a single transaction by the -application, so the cost difference is minimal, as it doesn’t scale per the -number of users. Both strategies require one transaction per user to claim their -rewards. +In both approaches, updating the rewards per claim period requires a single +transaction by the application, so the cost difference is minimal, as it doesn’t +scale per the number of users. Both strategies require one transaction per user +to claim their rewards. ZK compression is more cost-effective in storage costs, due to the reduced storage requirements of compressed data. Here is a hypothetical cost analysis to @@ -152,21 +152,20 @@ Storage Costs using a ZK compression distribution strategy: reward data - Compressed Data Size: Assuming a compression ratio of 50%, the total compressed data size would be approximately 500 KB - - Total Storage Cost: 500 * 1024 * 0.00000348 SOL/byte (per epoch) = 1.78 SOL + - Total Storage Cost: 500 _ 1024 _ 0.00000348 SOL/byte (per epoch) = 1.78 SOL - Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL - + We can extrapolate this across different numbers of reward distributions. | Number of Distributions | Merkle Tree Storage Cost (SOL) | ZK Compression Storage Cost (SOL) | -|-------------------------|--------------------------------|-----------------------------------| +| ----------------------- | ------------------------------ | --------------------------------- | | 1,000 | 0.06 | 0.03 | | 10,000 | 0.58 | 0.29 | | 100,000 | 5.80 | 2.90 | | 1,000,000 | 58.00 | 29.00 | | 5,000,000 | 290.00 | 145.00 | - ## Proof of Contribution DePIN networks generally need a way to prove the contribution from network @@ -175,7 +174,7 @@ provided the resource in question honestly and consistently. Reporting the contributions through Solana makes it possible to use the blockchain’s inherent security properties to enable the secure validation of the -contribution. +contribution. While almost all DePIN networks require proof-of-contribution in some form, the exact mechanism can vary significantly from protocol to protocol. A number of From 8e02b06ba2d3f72a991c506598074af4af773790 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:56:17 +0200 Subject: [PATCH 11/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 6128ad6e5..1de2227b4 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -30,10 +30,10 @@ While each DePIN network has a unique product focus, most DePIN networks utilize Solana for a common set of use cases. This guide is meant to help builders get oriented to these common on-chain DePIN use cases. Topics covered include: -- Minting and Managing a Token -- Rewards Distribution -- Proof of Contribution -- Governance +- [Minting and Managing a Token](#minting-and-managing-a-token) +- [Rewards Distribution](#rewards-distribution) +- [Proof of Contribution](#proof-of-contribution) +- [Governance](#governance) ## Minting and Managing a Token From cced94e6d7997c29e3a0afe844477ba49e0f8951 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:56:37 +0200 Subject: [PATCH 12/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 1de2227b4..6a6e03dae 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -64,7 +64,7 @@ distribution strategies. ### Token Management -Most teams utilize [Squads](https://squads.so/) for their on-chain treasury +Most teams utilize [Squads](https://squads.so/) for their onchain treasury management, also leveraging their multisig feature. ## Rewards Distribution From 8e2a5dbc325c24320c89cce7f2cb800d5fbafcef Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:56:48 +0200 Subject: [PATCH 13/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 6a6e03dae..3d84c6dca 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -82,7 +82,7 @@ transactions on the blockchain by allowing users to claim their rewards based on a published Merkle root. The application constructs a Merkle tree on a regular basis and publishes the -root on-chain. Each leaf node represents a recipient’s rewards. +root onchain. Each leaf node represents a recipient’s rewards. In order for users to claim their rewards, they generate a Merkle proof that demonstrates a particular leaf is part of the published Merkle root. Once their From ad73b986d96fababdb8da34f337dd55eb515fa35 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:57:01 +0200 Subject: [PATCH 14/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 3d84c6dca..a46fc3687 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -186,7 +186,7 @@ contribution models: ## Governance DePIN protocols tend to follow a path of measured, gradual decentralization that -shifts decision-making for the protocol to on-chain governance by token holders +shifts decision-making for the protocol to onchain governance by token holders over time. This could take the form of a social framework like a [DAO](https://www.realms.today/) or leverage [liquid restaking](https://docs.fragmetric.xyz/fragsol/). From 7bc17547c5a8e8d74cc1c0be6b11da739824638d Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:57:15 +0200 Subject: [PATCH 15/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index a46fc3687..ef1f47d7f 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -109,7 +109,8 @@ For networks that anticipate needing to distribute rewards to tens of thousands (or more) of nodes, participants, or contributors, a newer approach to rewards distribution is to use [ZK compression](https://www.zkcompression.com/). Instead of regular accounts, compressed accounts are generated for reward recipients, -minimizing the state and rent costs associated with account creation. +minimizing the state and [rent costs](/docs/core/fees.md#rent) associated with +account creation. Implementing ZK compression is often cheaper in terms of storage costs. However, because it is a relatively new feature, the level of ecosystem support and From 63fb7a1e00b890ce6e149735c9b67e8657cbe485 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:57:28 +0200 Subject: [PATCH 16/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index ef1f47d7f..2bee0b90b 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -122,8 +122,8 @@ See ### Cost analysis Let's estimate the cost of distributing rewards using both the Merkle tree -approach and the ZK compression. We'll consider transaction fees, rent costs, -and storage costs. +approach and the ZK compression option. We'll consider transaction fees, rent +costs, and storage costs. In both approaches, updating the rewards per claim period requires a single transaction by the application, so the cost difference is minimal, as it doesn’t From 5d18d7b3b47aa15bf61d10988eb3792eddedaf2a Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:57:42 +0200 Subject: [PATCH 17/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 2bee0b90b..f372c32ae 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -153,7 +153,8 @@ Storage Costs using a ZK compression distribution strategy: reward data - Compressed Data Size: Assuming a compression ratio of 50%, the total compressed data size would be approximately 500 KB - - Total Storage Cost: 500 _ 1024 _ 0.00000348 SOL/byte (per epoch) = 1.78 SOL +- Total Storage Cost: 500 \* 1024 \* 0.00000348 SOL/byte (per epoch) = 1.78 + SOL - Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL From 99b3f0cd7d52e2469f33481ed51eb8a6e5159d5c Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:57:54 +0200 Subject: [PATCH 18/20] Update content/guides/depin/getting-started.md Co-authored-by: Nick Frostbutter <75431177+nickfrosty@users.noreply.github.com> --- content/guides/depin/getting-started.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index f372c32ae..142e86ad5 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -39,9 +39,9 @@ oriented to these common on-chain DePIN use cases. Topics covered include: ### Token Minting -When minting a token on Solana, there are two token programs to choose from: -[the Token program](https://spl.solana.com/token) or -[the Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to +When minting a token on Solana, there are two token programs to choose from: the +[Token program](https://spl.solana.com/token) or the +[Token22 program](https://spl.solana.com/token-2022). There are tradeoffs to consider (discussed [here](https://solana.stackexchange.com/questions/9205/what-is-the-advantage-of-using-the-token22-token-extensions-program-over-the-old)). The recommended selection between the two options ultimately reduces to whether From 378cf667ad02f22f99977c104a8c517d087ca6bb Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Fri, 6 Dec 2024 18:59:55 +0200 Subject: [PATCH 19/20] Run prettier --- content/guides/depin/getting-started.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 142e86ad5..79250869f 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -153,8 +153,7 @@ Storage Costs using a ZK compression distribution strategy: reward data - Compressed Data Size: Assuming a compression ratio of 50%, the total compressed data size would be approximately 500 KB -- Total Storage Cost: 500 \* 1024 \* 0.00000348 SOL/byte (per epoch) = 1.78 - SOL +- Total Storage Cost: 500 \* 1024 \* 0.00000348 SOL/byte (per epoch) = 1.78 SOL - Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL From 83942dd93ebce771c852c13c8ddf9c08da5c4be8 Mon Sep 17 00:00:00 2001 From: Catalin Rosu Date: Mon, 9 Dec 2024 21:53:43 +0200 Subject: [PATCH 20/20] Copy updates --- content/guides/depin/getting-started.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/content/guides/depin/getting-started.md b/content/guides/depin/getting-started.md index 79250869f..320ddb1b0 100644 --- a/content/guides/depin/getting-started.md +++ b/content/guides/depin/getting-started.md @@ -26,6 +26,11 @@ leverage tokens to reward participants for contributing to and maintaining the infrastructure, creating a decentralized alternative to traditional centralized systems. Examples include wireless, content delivery, and mapping networks. +For instance, Helium creates a wireless network more cheaply than traditional +carriers by enabling individuals to deploy and maintain network hotspots. This +approach eliminates the need for centralized infrastructure investments and +operational costs, allowing the network to scale more cost-effectively. + While each DePIN network has a unique product focus, most DePIN networks utilize Solana for a common set of use cases. This guide is meant to help builders get oriented to these common on-chain DePIN use cases. Topics covered include: @@ -65,7 +70,7 @@ distribution strategies. ### Token Management Most teams utilize [Squads](https://squads.so/) for their onchain treasury -management, also leveraging their multisig feature. +management, and leverage features such as multi-sig and time-based lockups. ## Rewards Distribution @@ -201,7 +206,7 @@ or If you are a DePIN builder who has historically only been familiar with building on EVM, not to worry! A number of large DePIN teams who began on EVM chains have -successfully migrated to Solana (see RNDR, Geodnet, and Xnet, amongst others). +successfully migrated to Solana (see Render, Geodnet, and Xnet, amongst others). There are [specific resources to help developers make the transition from EVM to SVM](https://solana.com/developers/evm-to-svm). Bridge infrastructure like